shade

Потому что это азы SQL: если в выражении есть и агрегирующая функция, и просто неагрегируемые значения, то необходимо явным образом указать, что нужно по ним группировать.

Понятие еnd-to-end обозначает всего-навсего классификацию тестов по уровню, на котором тестируется система, и, само по себе, ничего не говорит ни о том, какие конкретно должны быть эти тесты, ни о том, какую роль они играют в общей стратегии обеспечения/проверки качества и, также, не является методикой тестирования. (Методика - это совсем другое понятие.)

Для понимания сути этого понятия хорошо сравнить его с модульным ("нижний" уровень) и интеграционным ("средний") тестированием на каком-нибудь конкретном примере. Давайте рассмотрим некий сферический webshop в вакууме. Предположим, в нем есть 50 классов и для большинства из них написаны модульные тесты. Они проверяют исключительно функционал конкретного модуля (чаще всего, класса), т.е. тот, что зависит только от самого модуля и ни от чего чего более. Потом есть интеграционные тесты. Они проверяют корректность работы отдельных "модулей", если их собрать вместе согласно архитектурe. Например, работает ли правильно "Корзина", состоящая, в свою очередь, из 10 классов (предварительно проверенных модульными тестами), или "Корзина", подключенная к "Вебморде" и т.д. Где-то повыше в этой иерархии есть такие интеграционные тесты, которые проверяют конкретный функционал всей системы. Например, отправляется ли юзеру мейлом копия оплаченного заказа...

И вот тут начинается самое интересное для понимания того, что такое end-to-end тестирование! Можно представить себе тест, проверяющий, что соответствующий мейл генерируется и сбрасывается SMTP серверу. Если SMTP сервер не рассматривать, как часть разрабатываемой системы, то этот тест вполне можно назвать end-to-end тестом (послали кучку HTTP запросов через "Вебморду" и проверили сброс мыла на SMTP - все зашибись!). Однако, если настройки и эксплуатация SMTP сервера - часть проекта (например, заказана разработка webshop "под ключ"), может оказаться, что это мыло будет отфильтровано каким-нибудь спам-фильтром, превысит лимит почтового ящика пользователя... короче, не дойдет до него. Тогда этот же самый тест уже нельзя считать end-to-end, а нужно бы было написать тест, проверяющий приход мыла в POP3/IMAP ящик. (Опять же, если это действительно нужно! Ибо, в зависимости от конкретных функциональных и нефункциональных требований, архитектор и QA инженер вполне могут найти возможность обеспечить адекватный контроль качества и без такого теста.)

Таким образом, end-to-end тесты, это такие интеграционные тесты, которые воздействуют на систему через ее самые внешние интерфейсы и проверяют ожидаемую реакцию системы через эти же интерфейсы. Почему именно интеграционные? Потому, что это единственное, что можно о них сказать наверняка: они по определению не могут быть модульными тестами. А все остальное: являются ли они одновременно приемочными, нагрузочными или еще какими - зависит только от общих плана/стратегии тестирования и той роли, которые эти тесты в них играют.

Управление светом (светильники, цветные led)

нет, баловство, которое надоест за неделю. А вот посвятить время выбору тех самых лед и продумать как их менять - да

"Непрерывные колонки"

у вас 200+м2 и божественная звукоизоляция каждой комнаты?

Управление некоторыми розетками

сделайте на каждую комнату отдельные автоматы на свет и питание. Отдельно на каждый прибор, который потребляет больше 1кВт

Датчики температуры/света

сильно зависит от типа отопления. Нужно делать для управления отоплением

Голосовое управление

у вас такое сильное желание отдавать все ваши секреты корпорациям бесплатно за проигрывание деспасито? Покушайте смузи и забудьте

Хороший ремонт - не умный дом, а хороший проект и умный подбор комплектующих
Никакое голосове управление вам не уберет плохо поставленный степлопакет

Что по-настоящему требуется от електрозависимого
- правильное расположение розеток, проводки, выключателей, мебели и кухни
- инфраструктура для охраны и безопасности

- хорошая метеостанция с разумным ее расположением и выводом датчика внутрь квартиры
- тесты различного типа освещения - лед економные, но если в помещении проводится много времени возможно стоит потратиться на другой тип освещения
- умное расположение выводов 1(10)-гигабитной сети
- подумать о возможности прокладки оптоволокна и инфраструктуры на ней

Господи пусть такие дизайнеры плодятся и размножаются!

А теперь по сути.

1) Названия лучше давать на английском.
2) Не злоупотреблять количеством шрифтов - вполне хватит двух или трех (Шрифт для текст, шрифт для заголовков, хитросделанный шрифт для подписи под лого или других декораций)
3) Хоть немного быть в курсе того, что можно сверстать, а что нет - например цвет заголовков градиентом или картинкой - можно реализовать на css, но работать это будет разве что в Chrome.
4) Не обрезать картинки делая их круглыми - используйте маски перекрытия или как то так, в верстке нет кругов только прямоугольники и квадрат как частный случай прямоугольника, но визуально сделать картинку круглой и скажем с бордером можно стилями - при этом исходник картинки будет квадратом или прямоугольником.
5) Используя тени делать их отдельно от изображений.
6) Элементы форм рисовать без фанатизма и стараться оставлять их такими какие отрисовываются браузером, в основном это касается чекбоксов/радиокнопок выпадающих списков, их можно стилизовать, но до сих пор это такие костыли и гемор, что аж горит, а потом горит у бекэндщиков, так как им все это реализовывать через задницу приходится.
7) Прежде чем нарисовать какую то супермега крутую красивую вещицу, спросить верстальщика (если есть возможность) сможет он это реализовать.

Хорошо знать, что они есть и какие задачи решают. Стоит понимать, что JavaScript и, в частности, код React приложения, сильно далек от классического ООП и во многих классических паттернах тут нет необходимости. А что-то уже реализовано в браузерных API и библиотеках которые вы используете.
В JavaScript и в React разработке используются свои паттерны и приемы. Просто вбейте в поисковике React patterns . Так же хорошо знать что такое принципы SOLID, DRY и прочее.

Решение:

• Называете одинаково на всех досках список ToDo
  
• В поиске вбиваете: list:ToDo
  
• Если нужно только активные list:ToDo is:open
  
• Если нужно только активные кроме доски NotDo list:ToDo is:open -board:NotDo
  
• Можно комбинировать запрос (фильтровать, минусовать) и сохранять эти запросы для расширенного тарифа
  

Фильтрация задач по спискам или доскам в Trello

Домен notificationcommunicationpatent.com зарегистрирован в июне этого года, сайт notificationcommunicationpatent.com безграмотно оформлен включая копирайты, это не может быть сайтом юридической компании.

Содержание патента не имеет никакого отношения к описанию на сайте. При этом патент скорей всего не имеет к вам никакого отношения к вашему приложению и у него совсем другой представитель:

Reiser & Partner Patentanwälte mbB
Weinheimer Straße 102
69469 Weinheim / DE

А у тебя здесь this не будет твоим компонентом, так как это stateless компонент, в виде чистой функции.

Если без immutablejs, то:
1.

return {
        ...state,
        items: [
          ...state.items,
          action.payload,
        ],

2.

return {
        ...state,
        items: state.items.map((item) => {
          if (item.id === action.payload.id) {
            return {
              ...item,
              name: action.payload.name,
            };
          }
          return item;
        }),
      };

Серьезно?!
forceUpdate() - черным по белому жеж ...

использование forceUpdate привести к каким то побочным эфектам

конечно может. Но вообще это скорее исключение из правил и лучше пользовать setState()

Если кратко:
setState() записывает данные в this.state и вызывает рендер.
forceUpdate() ничего не делает, а просто вызывает рендер. В принципе бесполезная функция, т.е. если ни props, ни state не изменились, то отрендерится один фиг тоже самое. Если честно даже в голову не приходит зачем это может понадобится, кроме каких-нить волшебных асинхронных костылей в render'e.