Я сделал на серве SG90. Не хватает плавности хода. Серва крутит слишком быстро и шумно. И было бы неплохо 360 градусов. Серва может только 270. Т.к. чтобы защититься от солнца лучше работает когда жалюзи закрыты в другую сторону. В остальном решение рабочее.
Есть форум, есть группа в телеграмме. Каких-то серьёзных трудностей не возникло.
Всё достаточно просто. Есть модули(драйверы), есть состояния. Эти состояния можно менять и подписываться на их изменение. Проблема в том, что эти состояния задаются строковыми константами и нет никакой проверки при удалении состояния или драйвера. Бага вылезет в рантайме.
Не каждый насос будет на кривом синусе генератора работать.
А вообще это извечный холивар радиаторы/теплые полы. Скажу, что надо и то и другое с нашими зимами. Причём теплый пол для комфорта догреть пол на 1-2 градуса (можно без него и тапочками обойтись). Фигачить в -30 на улице тёплый пол на 40 градусов, чтоб дом прогреть не будешь.
Если не знаете куда потратить вечер, то это Ваш вариант. Оформлял 2 полиса недавно, ушло 2 вечера. И заполнить данные на сайте какой-нибудь страховой мало, потом, как правило, ждёт квест с оформлением через систему Единый агент и частичным заполнением тех же данных и прикреплением тех же сканов.
Название IoC-контейнер лишено всякого смысла, если посмотреть что такое IoC. DI-контейнер как это названо у Симана мне нравится больше. Контейнер можно использовать как Service Locator, но вопрос был в другом
Да, компонент сам запрашивает то, что ему нужно в коде. Но он сам не создаёт конкретных реализаций. Он запрашивает их у локатора по абстракции. Это ли ни IoC? И тоже самое при инъекции в конструктор компонент всё равно прописывает то, что ему нужно только в публичном «контракте». Сути это не поменяло, только зависимости стали прозрачными и явными.
когда вы используете Service Locator, вы не используете IoC, у вас «прямое» управление.
Точно? На MSDN(раздел Related Patterns) написано, что Service Locator является специализированной версией IoC
Я до конца не доверяю википедии(раздел Implementation techniques), но там тоже сказано об этом.
Дак Service Locator является реализацией IoC или нет?
К сожалению && и || по-человечески не переопределишь
И если опять же смотреть на определение паттерна Спецификация из начала статьи, AutoSpec это точно реализация спецификации? Где же та цепочка объектов, связанных операциями булевой логики?
А можете объяснить чего Вы добились, используя такой подход? Т.е. какие плюсы подхода перевесили минусы в вашем случае.
Потому что
можно написать базовый объект для фильтрации чего-угодно
я здесь что-то не увидел. Получаем базовый класс, который подходит только для entities, у которых есть свойства Name и Rating. Очень большой риск использовать этот базовый класс не правильно, что приведёт к ошибке в run time
На самом деле это плохая идея для 3d печатных деталей. Ацетон растворяет внешний слой и потом долго высыхает. Деталь через недели 2 начинает растрескивания. Но самое страшное, когда ацетон попадет внутрь.
Не будет никакой промышленной революции 2.0 и не будет принтера в каждом доме пока пользоваться им не будет так же просто как микроволновкой. Сейчас печать на fdm-принтере это не просто. Ценник на принтер всё ещё кусается. А моделить для печати может далеко не каждый.
Попробуйте shinobi
Всё достаточно просто. Есть модули(драйверы), есть состояния. Эти состояния можно менять и подписываться на их изменение. Проблема в том, что эти состояния задаются строковыми константами и нет никакой проверки при удалении состояния или драйвера. Бага вылезет в рантайме.
А вообще это извечный холивар радиаторы/теплые полы. Скажу, что надо и то и другое с нашими зимами. Причём теплый пол для комфорта догреть пол на 1-2 градуса (можно без него и тапочками обойтись). Фигачить в -30 на улице тёплый пол на 40 градусов, чтоб дом прогреть не будешь.
Logcat я использовал, в чем с ним проблемы?
Это Вы про DIP?
Точно? На MSDN(раздел Related Patterns) написано, что Service Locator является специализированной версией IoC
Я до конца не доверяю википедии(раздел Implementation techniques), но там тоже сказано об этом.
Дак Service Locator является реализацией IoC или нет?
В случае с AutoSpec такой возможности, как я понял, нет и не предвидится. И вообще спецификация ли это тогда?
И если опять же смотреть на определение паттерна Спецификация из начала статьи, AutoSpec это точно реализация спецификации? Где же та цепочка объектов, связанных операциями булевой логики?
Потому что я здесь что-то не увидел. Получаем базовый класс, который подходит только для entities, у которых есть свойства Name и Rating. Очень большой риск использовать этот базовый класс не правильно, что приведёт к ошибке в run time
выглядит странно. Не понятно что оно должно делать. Можете привести пример как этим пользоваться? Спасибо!
PS: Не знаю как другим, для меня использование =>, когда строчек больше, чем одна, не прибавляет коду читаемости. Скорее наоборот.
На самом деле это плохая идея для 3d печатных деталей. Ацетон растворяет внешний слой и потом долго высыхает. Деталь через недели 2 начинает растрескивания. Но самое страшное, когда ацетон попадет внутрь.