А как много у вас устройств? Есть ещё и такой кейс: speech-to-command, особенно в случае неиросети, может неправильно интерпретировать какие-то задачи и повключать/повыключать не то. Если со светом - это просто досадный фейл, то в случае отопления может быть весьма жёстко (дом остынет или наоборот перегреется).
Всё-таки в таких делах, кажется, лучше оставить управление за человеком.
При найме столкнулся с тем, что даже самое простое тестовое задание (даже не в режиме live-coding) не делается в более чем половине случаев. Особенно жалко, если кандидат выглядит адекватным. Из тех, кто до тестового таки доходит, 9 из 10, что будет написана дичь.
В итоге имеем два стула: - сыграть в казино, дав кандидату тестовое и высокой вероятностью спугнуть - сыграть в казино, сделав оффер вроде бы адекватному товарищу
По себе же скажу, что если тестовое отнимет у меня больше часа, я забью и поищу ещё вакансии.
Помню, я знатно удивился, когда зарелизили diablo 3 и я не мог поиграть в сингл из-за того, что сервера заняты. Не меньше удивился, когда из-за плохого соединения у меня в том же сингле враги перемещались по карте рывками и их не удавалось убить. Собственно, больше с этими ребятами дела решил не иметь, как и с другими, кто разрабатывает игры, основываясь на подобной модели.
У меня бы возникло множество вопросов к такой постановке задачи. Если это какой-то сервис в вакууме - ну ок. 1. Почему приложению искусственно ограничивают возможность использовать доступные ядра на 100%? (Если gunicorn такое умеет, конечно, я не знаю), т.к. rabbitmq будет передавать сообщения значительно медленнее, чем утилизируются ресурсы процессора. 2. Почему именно rabbitmq, а не kafka? 3. Что будет, если сервис за rabbitmq откажет, что получит пользователь и когда? 4. Что будет в случае отказа rabbitmq? Вообще, если мы используем очереди, мы предполагаем, что ответ на запрос поступит "когда-нибудь", а в вашей схеме пользователь отправляет, по всей видимости, синхронный запрос. Это повлечёт очень большие задержки, если кто-то в беке затупит. Следовательно, на фронте тоже должен будет стоять какой-то листенер, который будет обрабатывать "ответы" из очереди - ещё одна точка отказа Я понял, что не вы такую схему придумали, но всё же было бы здорово выяснить у того, кто такую задачу поставил: зачем вообще порождать такого монстра?
Вы всё-таки решаете какую-то проблему и публике очень хочется понять: какую именно? Вместо этого вы предлагаете туториал, как решать неизвестную проблему.
Какое-то странное ощущение от чтения получил. В советское время у властей была такая практика: перепечатать интервью какого-нибудь известного зарубежного коммуниста, или даже пригласить оного на какое-нибудь мероприятие, чтобы тот восхитился мудростью советского руководства, стойкостью советских граждан и поругал проклятый капиталистический режим.
Советского гражданина, при этом, от побега удерживали не только нравоучениями, но и законом. Программиста, который может открыть эту статью, пролистнуть в самый низ до блока "средняя зарплата в IT", закон удерживает примерно никак.
C wifi вендорлок можно также легко устроить. Алиса/Гугл/Эппл - ещё веселее.
Свой умный дом я начал строить два года назад на основе wifi, и перешёл таки на zigbee. Причины следующие: - вендорлок на wifi-устройствах. Алиса, конечно, что-то решает, но не всё. Кроме того, на wifi соединение рвётся чаще (субъективно) и не всегда восстанавливается - приходится перезагружать само устройство (на оставшихся wi-fi розетках в расписании стоит перезагрузка раз в сутки, на всякий случай) - отсутствие гибких настроек (например, включить что-то, если температура ниже отметки, но время в диапазоне с 23 до 7), или рециркуляция у меня включается по датчику движения, но не чаще, чем раз в полчаса. Я с трудом представляю, как такое сделать алисой, а вот HomeAssistant - запросто. - нет интернетов = нет команд на устройства, а это за городом случается частенько - зигби нетребовательны к питанию, следовательно, могут работать на батарейках. В градусниках батарейки не израсходовались даже на половину за 2 года
И, что самое важное, в случае с zigbee можно вообще не заморачиваться за совместимость: если что-то не работает, можно написать самому, т.к. оно всё через mqtt общается.
Есть хамечательный концепт у Уоттса в "Революции в стоп-кадрах": люди путешествуют по галактике на астеройде... с чёрной дырой внутри, в качестве источника энергии и двигателя.
"Кем вы видите себя через 5 лет?" - ведь хороший вопрос, на самом деле. Важен даже не ответ, а сам факт того, что ответ существует. А ещё к этому вопросу можно добавить следующий: "Что вы для этого делаете?"
А как много у вас устройств? Есть ещё и такой кейс: speech-to-command, особенно в случае неиросети, может неправильно интерпретировать какие-то задачи и повключать/повыключать не то.
Если со светом - это просто досадный фейл, то в случае отопления может быть весьма жёстко (дом остынет или наоборот перегреется).
Всё-таки в таких делах, кажется, лучше оставить управление за человеком.
Есть какие-то плагинчики для того же home assistant типа text-to-speech. Зачем вам такая жирная нейросеть?
Ну и небольшое имхо: голосовое управление домом - в основном бесполезная фича.
При найме столкнулся с тем, что даже самое простое тестовое задание (даже не в режиме live-coding) не делается в более чем половине случаев. Особенно жалко, если кандидат выглядит адекватным.
Из тех, кто до тестового таки доходит, 9 из 10, что будет написана дичь.
В итоге имеем два стула:
- сыграть в казино, дав кандидату тестовое и высокой вероятностью спугнуть
- сыграть в казино, сделав оффер вроде бы адекватному товарищу
По себе же скажу, что если тестовое отнимет у меня больше часа, я забью и поищу ещё вакансии.
Помню, я знатно удивился, когда зарелизили diablo 3 и я не мог поиграть в сингл из-за того, что сервера заняты. Не меньше удивился, когда из-за плохого соединения у меня в том же сингле враги перемещались по карте рывками и их не удавалось убить. Собственно, больше с этими ребятами дела решил не иметь, как и с другими, кто разрабатывает игры, основываясь на подобной модели.
Новых прямых поставок не будет.
А после оффера crudы ковыряем...
У меня бы возникло множество вопросов к такой постановке задачи. Если это какой-то сервис в вакууме - ну ок.
1. Почему приложению искусственно ограничивают возможность использовать доступные ядра на 100%? (Если gunicorn такое умеет, конечно, я не знаю), т.к. rabbitmq будет передавать сообщения значительно медленнее, чем утилизируются ресурсы процессора.
2. Почему именно rabbitmq, а не kafka?
3. Что будет, если сервис за rabbitmq откажет, что получит пользователь и когда?
4. Что будет в случае отказа rabbitmq?
Вообще, если мы используем очереди, мы предполагаем, что ответ на запрос поступит "когда-нибудь", а в вашей схеме пользователь отправляет, по всей видимости, синхронный запрос. Это повлечёт очень большие задержки, если кто-то в беке затупит. Следовательно, на фронте тоже должен будет стоять какой-то листенер, который будет обрабатывать "ответы" из очереди - ещё одна точка отказа
Я понял, что не вы такую схему придумали, но всё же было бы здорово выяснить у того, кто такую задачу поставил: зачем вообще порождать такого монстра?
Вы всё-таки решаете какую-то проблему и публике очень хочется понять: какую именно? Вместо этого вы предлагаете туториал, как решать неизвестную проблему.
Какое-то странное ощущение от чтения получил. В советское время у властей была такая практика: перепечатать интервью какого-нибудь известного зарубежного коммуниста, или даже пригласить оного на какое-нибудь мероприятие, чтобы тот восхитился мудростью советского руководства, стойкостью советских граждан и поругал проклятый капиталистический режим.
Советского гражданина, при этом, от побега удерживали не только нравоучениями, но и законом. Программиста, который может открыть эту статью, пролистнуть в самый низ до блока "средняя зарплата в IT", закон удерживает примерно никак.
C wifi вендорлок можно также легко устроить.
Алиса/Гугл/Эппл - ещё веселее.
Свой умный дом я начал строить два года назад на основе wifi, и перешёл таки на zigbee. Причины следующие:
- вендорлок на wifi-устройствах. Алиса, конечно, что-то решает, но не всё. Кроме того, на wifi соединение рвётся чаще (субъективно) и не всегда восстанавливается - приходится перезагружать само устройство (на оставшихся wi-fi розетках в расписании стоит перезагрузка раз в сутки, на всякий случай)
- отсутствие гибких настроек (например, включить что-то, если температура ниже отметки, но время в диапазоне с 23 до 7), или рециркуляция у меня включается по датчику движения, но не чаще, чем раз в полчаса. Я с трудом представляю, как такое сделать алисой, а вот HomeAssistant - запросто.
- нет интернетов = нет команд на устройства, а это за городом случается частенько
- зигби нетребовательны к питанию, следовательно, могут работать на батарейках. В градусниках батарейки не израсходовались даже на половину за 2 года
И, что самое важное, в случае с zigbee можно вообще не заморачиваться за совместимость: если что-то не работает, можно написать самому, т.к. оно всё через mqtt общается.
В комментариях к некоторым товарам люди пишут, что в инструкции указано "отключить антивирус", что намекает на использование кряка.
Так что тут ещё и покупателя обманывают, а не только разработчика.
Есть хамечательный концепт у Уоттса в "Революции в стоп-кадрах": люди путешествуют по галактике на астеройде... с чёрной дырой внутри, в качестве источника энергии и двигателя.
А ведь когда-то сайты, которые весили по 10-20кб были нормой, а не "техночелленджем".
"Мы вам перезвоним"
"Кем вы видите себя через 5 лет?" - ведь хороший вопрос, на самом деле. Важен даже не ответ, а сам факт того, что ответ существует. А ещё к этому вопросу можно добавить следующий: "Что вы для этого делаете?"