Я зазвичай відео не пишу. Якщо бути більш точним — я вперше використав відео у якості відповіді. В мене просто склалось враження, що без наглядної демонстрації мене можуть не зрозуміти, а писати цілий пост в коменті не дуже хотілось. А стосовно простого випадку — то я не вигадував нічого нового, а скористався прикладами із статті.

Я повністю згоден, що все залежить від ситуації і універсальних методів не існує. Холіварити про ті 4 пункти не бачу сенсу (3 пункт не зміг зрозуміти взагалі). Тут вже кожен хай сам собі вирішує в залежності від того за яким флоу пощастило працювати і в якому вигляді легше сприймати інформацію.

Є ж опція поставити HA, а Node Red використовувати для більш складних автоматизацій 🤔 тоді буде все а одному. MPD в HA також легко додати.

Єдине, що якщо вдома немає сенсорів та інших розумних речей, то, дійсно, буде нудно...

От якщо він ще на українську перейшов, то взагалі ціни б йому не було :)

Доречі в HA є такі штуки як Helpers (в розділі Settings — Devices and Services). А там є такий вид хелпера як Group, який дозволяє згрупувати декілька Entity в одну сутність.

Наприклад так можна об’єднати все світло в домі а одну групу і керувати їм через одну сутність (зручно робити автоматизацію типу «вимкнути все світло»)

Але я хочу розповісти не про світло, а про інтеграцію Ukraine Alerts. Ця інтеграція має 6 різних типів тривог. Замість того, щоб перераховувати їх усі в автоматизації, їх можна об’єднати в одну групу. Так буде значно зручніше. І ще тригеру типу Device краще використовувати State.

Щось мене зтригирело і я записав відос в якому всі приклади з статі вирішуються через git rebase -i:

Я не говорю, що --onto це погано. Просто interactive значно гнучкіший (можна змінювати порядок комітів, їх текст, об’єднувати і т.д.). Те саме і в порівнянні з cherry-pick.

Хоча, cherry-pick я використовую у випадках, коли треба пікнути один коміт, або коли треба забрати декілька комітів з середини іншої гілки. Тут дійсно з rebase буде не зручно працювати (хоча знову ж таки — це можливо, бо interactive режим дуже потужний).

Так як rebase -i закриває усі потреби, то я не бачу сенсу забивати голову додатковими командами. Навіть якщо --onto можна використовувати паралельно з --interactive. Це просто зайве когнітивне навантаження. Кому воно потрібно? 😅

Але основна мета мого коменту — захистити інших користувачів від стверджень типу, що «Interactive режим не даёт» і що «Непонятно сравнение». І те, що «інтерактивний режим сам по собі не дає ніякого onto» це теж не важливо, якщо твоя задача змінити дерево комітів, а не використати --onto. Сподіваюсь, що мій відос достатньо наглядно демонструє, що тут є, що порівнювати. А далі нехай кожний обирає сам, що йому підходить більше. Я вже свій вибір зробив. :)

Як це не дає? Абсолютно все, що описано в пості можна робити в інтерактивному режимі. І це буде значно зрозуміліше і простіше. Не треба вираховувати правильний хеш коміта, бо в тебе буде список комітів, з яким ти можеш робити будь що: видаляти, змінювати порядок, об’єднувати, змінювати текст.

`git rebase -i` дає більше можливостей і набагато простіший для розуміння

+

Дякую за лінк. Хороші статті. Було б круто якщо б десь була інфа, що в одній системі неможливо виконати якесь завдання з яким без проблем справляється інша. Але схоже, що обидві системи досить круті і обирати потрібно чисто за суб’єктивними вподобаннями. Тим не менш, схоже що HA краще підійде для новачків і тих, хто не має бажання витрачати багато часу на розробку розумного будинку.

Дякую за статтю. Як на мене з цієї статті можна було зробити декілька 😅.

А чи є у когось досвід використання інших систем? Типу openhab, domoticz, iobroker. Цікаво як увесь цей зоопарк у порівнянні з home assistant? HA це дійсно топове рішення на сьогодні?

Стоимость разработки на Java выше. Искать Java специалистов сложнее. Хороший выбор для проекта с ограниченным бюджетом!

пожалуй, тебе стоит написать об этом статью на DOU, а то тебе приходится каждый раз все разжевывать другим.

Мог бы просто скидывать линку на статью и не было бы больше вопросов. Комьюнити будет тебе благодарно за вклад!

боюсь, на этом я выхожу из чата

то, что ты описал можно заимплементить используя REST соглашения. Вопрос: зачем выдумывать велосипеды?

ты сам определяешь насколько будет гранулярная твоя апишка. Сущностью может быть как вся страница целиком, так и каждое отдельное слово со страницы. Это определяет не РЕСТ, а проектировщик апи.

нету смысла выдумывать всякие наркоманские кейсы, в которых будет неприменим РЕСТ подход. Никто не спорит, что бывают специфические задачи, для которых нужны специфические решения. Но судя по коментам, чаще всего проблема не в специфических задачах, а в неумении разработчиков анализировать эти самые задачи

Боюсь, что проблема не в ресте, а в программистах 😅

Не могу понять при чем тут транзакционная целостность? РЕСТ это набор соглашений по части нейминга и структурирования ендпоинтов АПИ. Это правила построения внешнего интерфейса для взаимодействия с системой

В то время, как транзакционная целостность это уже больше характеристика системы. Эта характеристика не каждой системе нужна, между прочем. Но если даже говорить о транзакционной целостности, то как бы http запросы из коробки атомарны. То есть если у тебя появились проблемы с транзакционной целостностью то, пожалуй, проблема не в апи, а в той системе, которую ты спроектировал.

Но даже если так получилось, что система под капотом — кривая. Написать рест апи, которая может в транзакционную целостность — совсем не проблема.

И вправду. Лучше вместо популярного и всем понятного REST написать какой-то треш, в котором никто не разбирается.

Лучше вместо известного стека под капотом юзать самописные велосипеды. Не потому, что они дают «преимущество», а потому, что «мы ведь умные и лучше знаем».

А потом дело за малым — называем это «корпоративная бизнес-логика, энтерпрайз» и делаем вид, что что-то понимаем в тонких материях.

Жаль только, что все клиенты уйдут к конкурентам, которые пишут людские АПИ и что найти новых сотрудников, которые согласятся работать с «кодом победителей олимпиад», будет ой как не просто.

версионирование это один из методов обеспечения обратной совместимости 😅

Хороший обзор. Спасибо!

тут только нету смысла говорить о легаси, так как все равно заходит речь о том, чтобы этот легаси переписывать :) Эта статья о разных способах добавления темизации на проект.

Никакие легаси и микросервисы тут вообще ни при чем. С таким же успехом можно было дописать все то, что предложил Bogdan Shyiak и смысл статьи не поменялся бы.