Мне удобно, проблемы будут если надо будет масштабироваться. А мне не надо, производительности хватает со стократным запасом. Это же умный дом, он в одном домохозяйстве крутится, у него полтора пользователя, которые предпочитают его вообще не трогать, пока работает. А учитывая то, что масштабирование/резервирование не требуется, можно извлекать выгоду из того, что состояние системы не распределено, персистентность не требуется, следовательно его можно тупо держать в памяти одного процесса и прекрасно обходиться без системы очередей (если не считать таким mqtt-брокер) и баз данных.
Единственная моя проблема (что нужно довести до ума) в том, что я не знаю как правильно организовать сборку проекта с фронтендом, который хочу распространять целиком через pypi (чтобы pip install, конфиг поправил, системд юнит включил и работает). Бандлить в питоний пакет собранный JS стрёмно, а как без сборки вебпаком использовать сторонние библиотеки (я использую jsonrpc, хотя мог бы болт забить и на это) - не знаю. Может надо дистрибьюцию на докер-образ переводить, но это кажется совсем уж шизой, ради 40 строк на JS и 600 на питоне (где 200 - тесты).
Не понимаю как из выбора монолитной архитектуры следует требование писать home assistant или лучше, к слову.
Где-то полтора года назад решил сделать самопальный примитивный умный дом. Это, наверное как todo-листы у людей, которые дорвались до mqtt. Плюс захотелось немного поделать что-то отличное от работы, без микросервисов и прочего, а реально компактный монолит (расписание, приём топиков из mqtt с блокировками расписания, сбор данных из внешнего мира, API + экспорт метрик + веб-интерфейс - всё в одном процессе, просто в разных asyncio.Task), пусть и на питоне. Сейчас что-то распухло до 50мб потребление памяти, но было бы время, мне кажется получилось бы до 25 ужаться. Где-то с 0.0.4 версии ушёл в хардкод и пока его не причешу, не заребейзю всё по человечески - не буду публиковать. Беда в том, что с этого момента прошло полгода, а фич я в свой проект добавил эгегей. Да и он особо никому не нужен, лол.
Концептуально - идея прикольная. Нет, серьёзно. Мне нравится.
Но я не совсем понимаю, как вы в реальной системе планируете привязывать SQL-запрос к какому-то идентификатору. Это надо структуру приложения менять - складировать куда-то SQL-запросы, пусть и генерируемые через ORM, чтобы потом это место как-то парсить. А если там query-builder какой-то, у которого итоговый SQL зависит от входных параметров? Из логов выхватывать? Но как их тогда с предыдущими версиями сопоставлять?
Число INNER JOIN тоже, конечно те ещё попугаи. Лучше, чем ничего, но и вредить может. К примеру было 3 отдельных последовательных SQL-запроса не под транзакцией. Объединили их под одну транзакцию? Стало хуже? Лучше? Объединили их с помощью JOIN - стало лучше или хуже? Как себя стал пул соединений чувствовать под нагрузкой от этого? А если таких запросов -> JOIN'ов 10? 20? Как себя ведёт планировщик постгри, переключившись на всякие генетические алгоритмы? Но вы вроде понимаете это и обозначили что JOIN - это просто пример.
Этот подход хорошо сработает для вторичных систем, по большей части состоящих из набора SQL-запросов. Или вы таки применяете его где-то ещё?:)
Да. Социальные сети - они про то чтобы делиться, а не про долгосрочное надёжное хранение. В целом, соцсети, в которых нет функции "скачать файл" - странный выбор для такого хранения роликов. Пенсионерам только и остаётся, что свой Nextcloud поднимать.</сарказм></тоска>
На всякий случай прикрутил себе в DNS-сервер вот такую регулярку, прошёлся по настройкам, поотрубал рекламу ещё в трёх разделах кроме раздела с рекламой и успокоился совершёнными полумерами.
Пёстрая задняя стенка монитора - странная штука. В офисе коллег будет раздражать и резать глаза, дома - скорее всего будет не видна, т.к. будет повёрнута к стенке. Перфорированная ножка монитора - ещё более странная нефункциональная штука. Плоская мышь - это эргономично? Обычная мембранная клавиатура а-ля оклик из DNS - это добавленная ценность для владельца?
У меня есть пример, когда осмысленно не закрывал файлы. Это утилиты, единственная задача которых - обработать файл. Контекстный менеджер в таком случае уже существует и называется "процесс операционной системы". Завершается он - закрываются и все его файлы :)
Образование. Новый стандарт беспроводной связи расширит возможности для дистанционного и смешанного обучения, обеспечив стабильное подключение большого числа учащихся и преподавателей к образовательным платформам и ресурсам.
Не верю я, что на дистанционке вопрос количества подключающихся удалённо имеет бутылочное горлышко в виде локальной беспроводной сети.
«30 минут физической активности умеренной интенсивности в неделю, при наличии занятий 52 недели в году, связаны с дополнительными 0,010677 годами жизни».
Стало интересно, насколько нелинейна формула и сколько часов выдаст 1 час тренировок 1, 2 или 3 раза в неделю. Или 30 минут 6 раз в неделю. В упор не нашёл числа 0,010677 в статье, которую цитируете в конце. Запятую как разделитель на точку менял. Точность сокращал. Можете ткнуть носом, с какой страницы вы это взяли?
Мне удобно, проблемы будут если надо будет масштабироваться. А мне не надо, производительности хватает со стократным запасом. Это же умный дом, он в одном домохозяйстве крутится, у него полтора пользователя, которые предпочитают его вообще не трогать, пока работает. А учитывая то, что масштабирование/резервирование не требуется, можно извлекать выгоду из того, что состояние системы не распределено, персистентность не требуется, следовательно его можно тупо держать в памяти одного процесса и прекрасно обходиться без системы очередей (если не считать таким mqtt-брокер) и баз данных.
Единственная моя проблема (что нужно довести до ума) в том, что я не знаю как правильно организовать сборку проекта с фронтендом, который хочу распространять целиком через pypi (чтобы pip install, конфиг поправил, системд юнит включил и работает). Бандлить в питоний пакет собранный JS стрёмно, а как без сборки вебпаком использовать сторонние библиотеки (я использую jsonrpc, хотя мог бы болт забить и на это) - не знаю. Может надо дистрибьюцию на докер-образ переводить, но это кажется совсем уж шизой, ради 40 строк на JS и 600 на питоне (где 200 - тесты).
Не понимаю как из выбора монолитной архитектуры следует требование писать home assistant или лучше, к слову.
Где-то полтора года назад решил сделать самопальный примитивный умный дом. Это, наверное как todo-листы у людей, которые дорвались до mqtt. Плюс захотелось немного поделать что-то отличное от работы, без микросервисов и прочего, а реально компактный монолит (расписание, приём топиков из mqtt с блокировками расписания, сбор данных из внешнего мира, API + экспорт метрик + веб-интерфейс - всё в одном процессе, просто в разных asyncio.Task), пусть и на питоне. Сейчас что-то распухло до 50мб потребление памяти, но было бы время, мне кажется получилось бы до 25 ужаться. Где-то с 0.0.4 версии ушёл в хардкод и пока его не причешу, не заребейзю всё по человечески - не буду публиковать. Беда в том, что с этого момента прошло полгода, а фич я в свой проект добавил эгегей. Да и он особо никому не нужен, лол.
И где он через 10 лет возьмёт сеньоров?
[ДАННЫЕ УДАЛЕНЫ]
Концептуально - идея прикольная. Нет, серьёзно. Мне нравится.
Но я не совсем понимаю, как вы в реальной системе планируете привязывать SQL-запрос к какому-то идентификатору. Это надо структуру приложения менять - складировать куда-то SQL-запросы, пусть и генерируемые через ORM, чтобы потом это место как-то парсить. А если там query-builder какой-то, у которого итоговый SQL зависит от входных параметров? Из логов выхватывать? Но как их тогда с предыдущими версиями сопоставлять?
Число INNER JOIN тоже, конечно те ещё попугаи. Лучше, чем ничего, но и вредить может. К примеру было 3 отдельных последовательных SQL-запроса не под транзакцией. Объединили их под одну транзакцию? Стало хуже? Лучше? Объединили их с помощью JOIN - стало лучше или хуже? Как себя стал пул соединений чувствовать под нагрузкой от этого? А если таких запросов -> JOIN'ов 10? 20? Как себя ведёт планировщик постгри, переключившись на всякие генетические алгоритмы? Но вы вроде понимаете это и обозначили что JOIN - это просто пример.
Этот подход хорошо сработает для вторичных систем, по большей части состоящих из набора SQL-запросов. Или вы таки применяете его где-то ещё?:)
А любой Blue-ray привод не прокатит разве? Там сделали проприетарный разъём какой-то?
Какое прекрасное импортозамещение сайта в доменной зоне
.itДа. Социальные сети - они про то чтобы делиться, а не про долгосрочное надёжное хранение. В целом, соцсети, в которых нет функции "скачать файл" - странный выбор для такого хранения роликов. Пенсионерам только и остаётся, что свой Nextcloud поднимать.</сарказм></тоска>
Вот у меня после тренировки большая проблема дойти до дома и не ВОЖРАТЬ БЫ ЧЕГО-НИБУДЬ ЭДАКОГО, хотя идти минут пять.
На всякий случай прикрутил себе в DNS-сервер вот такую регулярку, прошёлся по настройкам, поотрубал рекламу ещё в трёх разделах кроме раздела с рекламой и успокоился совершёнными полумерами.
Ещё бы понять как отучить его предлагать.
Замыкаем круг, отправляем водителей в шахты?
Я бы не отказался от возможности по воздуху бэкапить данные куда-то к себе, но не знаю как это сделать штатными средствами в iOS. Подскажете?
Пёстрая задняя стенка монитора - странная штука. В офисе коллег будет раздражать и резать глаза, дома - скорее всего будет не видна, т.к. будет повёрнута к стенке. Перфорированная ножка монитора - ещё более странная нефункциональная штука. Плоская мышь - это эргономично? Обычная мембранная клавиатура а-ля оклик из DNS - это добавленная ценность для владельца?
Меня изрядно вкорёжило в статье:
В смысле, блин, устарел? Почему браузер за меня будет решать что скачиваемый мной файл устарел?
У меня есть пример, когда осмысленно не закрывал файлы. Это утилиты, единственная задача которых - обработать файл. Контекстный менеджер в таком случае уже существует и называется "процесс операционной системы". Завершается он - закрываются и все его файлы :)
Часть не современные.
Часть не развитые.
Часть не может.
Часть не хочет.
К чему грести всех под одну единственную причину?
Не верю я, что на дистанционке вопрос количества подключающихся удалённо имеет бутылочное горлышко в виде локальной беспроводной сети.
Стало интересно, насколько нелинейна формула и сколько часов выдаст 1 час тренировок 1, 2 или 3 раза в неделю. Или 30 минут 6 раз в неделю. В упор не нашёл числа 0,010677 в статье, которую цитируете в конце. Запятую как разделитель на точку менял. Точность сокращал. Можете ткнуть носом, с какой страницы вы это взяли?