чтобы не накручивать условия для своих же странных аналогий просто попробуйте аргументировать свое мнение БЕЗ аналогий. Например в вашем первом комментарии достаточно было бы написать, что SE часто сталкиваются с недокументированными системами, с плохой организацией процесса и т.п.
К чему там лего совершенно непонятно.
С этими проблемами может столкнуться равнозначно и "инженер" и "рабочий", но в случае рабочего — исправление и разбор — не его проблема. И инженеры в других областях абсолютно так же выгорают. Спросите любого инженера/архитектора/проектировщика со стройки например.
плюс специализированные ядра в новых процессорах вполне себе улучшают производительность. задачи в основном типовые и выделять под них более эффективные специализированные ядра -- логичное решение, а универсальные пусть работают над тем, что пока не получилось или не имеет смысла автоматизировать.
в postgresql тоже работа с индексами очень важна и инструменты там такие, что часто даже читать данные из таблицы после сканирования индекса не требуется. я когда-то давно ушел на постгрес из-за того что лучше понимаю логику его работы и, кажется, не ошибся. очень предсказуемая субд.
У нас всего 20 млн уведомлений и архитектура попроще, но тоже экономического смысла перевода уведомлений подрядчикам не нашлось. Получается на порядки дороже.
у меня кнопки из серии aqara, в них ни в одной скотч не нужно отдирать. у меня в целом больше нагрузки на датчики движения и открывания/закрывания дверей, чем на кнопки. Кнопки для меня это эдакий фоллбек, когда автоматика сработала не так как надо. практически не пользуемся ими.
Зигби устройства, выключатели, датчики и кнопки у меня Xiaomi, а освещение Philips, плюс всякие умные розетки и реле с алиэкспресс. Крутится все на домашнем сервере, я в него просто свисток воткнул. У филипса огромные плюсы в том, что там автономные протоколы зигби реализованы, то есть выключатель филипс может управлять лампами филипс напрямую без сервера, conbee поддерживает программирование таких связок. Собственно я бы не решился делать проводной умный дом, зная сколько гибкости сейчас дают беспроводные решения.
Надо сказать, conbee работает гораздо стабильнее чем любое решение с zigbee2mqtt, ох как я с зигби намучался, прежде чем удалось собрать нормальное рабочее решение на conbee + deconz + hassio
чтобы не накручивать условия для своих же странных аналогий просто попробуйте аргументировать свое мнение БЕЗ аналогий. Например в вашем первом комментарии достаточно было бы написать, что SE часто сталкиваются с недокументированными системами, с плохой организацией процесса и т.п.
К чему там лего совершенно непонятно.
С этими проблемами может столкнуться равнозначно и "инженер" и "рабочий", но в случае рабочего — исправление и разбор — не его проблема. И инженеры в других областях абсолютно так же выгорают. Спросите любого инженера/архитектора/проектировщика со стройки например.
Плохая аналогия подобна котенку с дверцей, ага. Сборка лего по инструкции — не работа инженера.
ну по сути это упрощение и есть :)
у них там не такая нагрузка, кеширование нормальное должно было бы помочь вполне.
плюс специализированные ядра в новых процессорах вполне себе улучшают производительность. задачи в основном типовые и выделять под них более эффективные специализированные ядра -- логичное решение, а универсальные пусть работают над тем, что пока не получилось или не имеет смысла автоматизировать.
в данном случае в пятницу лучше не выкатывать по причине того что это пик продаж всей недели, а не потому что разработчик забухал :)
кажется любая система проходит путь усложнение -- затык -- упрощение -- усложнение -- затык -- упрощение. это норма :)
вероятно взаимосвязанная логика помешала, но надменный тон конечно вам не к лицу.
заменить бд никогда не проще. да и хайповые базы данных для долгих проектов всяко хуже чем старые добрые mysql, постгрес или коммерческие.
в postgresql тоже работа с индексами очень важна и инструменты там такие, что часто даже читать данные из таблицы после сканирования индекса не требуется. я когда-то давно ушел на постгрес из-за того что лучше понимаю логику его работы и, кажется, не ошибся. очень предсказуемая субд.
здесь проблема не в совмещении базы данных, а в увеличении нагрузки из-за пушей. собственно это увеличение нагрузки -- и есть цель этих пушей
Стандартная библиотека — уже в некотором роде фреймворк.
Чтобы их мнение показали по телевизору им даже существовать, в принципе, не обязательно. Очень слабый аргумент.
У нас всего 20 млн уведомлений и архитектура попроще, но тоже экономического смысла перевода уведомлений подрядчикам не нашлось. Получается на порядки дороже.
За первый год ни одна батарейка не села. Но это не важно, батарейки мониторятся и не такой уж это и сложный процесс.