kn0ckn0ck

hcidump --raw &
hcitool lescan

более сложные варианты расписаны здесь.

Рекомендую "библию": Томас Кайт. Oracle для профессионалов. Архитектура, методики программирования и особенности версий.

Если на ПК я могу одновременно (разными приложениями) снимать звук со встроенного микрофона или Bluetooth-гарнитуры, то видимо проблем с подключением к ПК нескольких микрофонов через внешнюю звуковушку (USB) не должно быть.

Если в качестве "сервера" для умного дома используется микрокомпьютер с Linux, то также проблем быть не должно, поскольку все приложения параметризуются логическим устройством (конкретным микрофоном).

Может быть отказаться от проводов и сделать кластер из нескольких "серверов" (на базе дешевых микрокомпьютеров, например), к каждому из которых подключить по микрофону?

Глупее чем поморгать светодиодами на малинке может быть только инвестиция в биткоин. Вы определитесь в том, к чему хотите прийти через год.

Опыт полученный на ардуинке скорее всего останется личным опытом, за него никто платить не станет. Опыт полученный на малинке очень может пригодиться в работе. Хотя бы потому, что там линукс и его придется изучить на уровне начинающего пользователя как минимум.

Что для современного программиста линукс надеюсь не нужно рассказывать.

Предыдущий разработчик сделал все правильно, по классике.

Предложенный альтернативный вариант ничем не удобнее с точки зрения построения реляционных запросов, скорее даже наоборот - гораздо более неудобный и тормозной в перспективе.

Оставьте как было.

Оу да, это фундаментальная проблема любого ORM-тула - инкаспулируя специфику хранения, они создают иллюзию простоты работы с РСУБД.

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

Серьезная работа с БД никогда не может идти от ORM-тула, только от самой БД, а тут возникают индексы всех мастей, партиционирование и другие всякие хитрости оптимизации доступа/хранения.

Иллюзии дизайна, выстроенного от ORM, рушатся с грохотом, что приводит к задачам типа "все надо переделать!" Об этом и намекает автор, что мол, жизнь чуть сложнее, чем кажется.

Давайте идти от фактов. Нейросеть - это модель. Полезная модель - очень большая модель. Ну, например, tensorflow-модель для распознавания пары русскоязычных слов (в условиях разных тембров и шума) займет что-то около 10 ГБ. Работа с такой моделью займет приличное количество ресурсов. Где тут микроконтроллер?

Для начала имеет смысл с этим разобраться и научиться готовить. Затем уже встанет задача оптимизации всего (хранения и времени вычисления), чтобы это как-то можно было бы запихинуть в ПЛИС или подобное. Такие вещи точно делают, но это сугубо алгоритмическая/математическая история.

Кажется тут речь об организации Access Point, которая в том числе может пошарить свой интернет (из USB донгла)

Ну вы уже ваще - коллаборация в семье через таск-трекер... хотя конечно любую идею можно довести до абсурда.

Стикеры вам в помощь:

MegaD

ФРИИ
Кто все эти люди?

Тадаам! Task Scheduler, встречайте!

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

Вы все сильно усложняете :) Есть два основных подхода, которые должны быть хорошо известны тем, кто должен писать unit-тесты:

a. Arrange/Act/Assert
b. Given/When/Then

1. SP - это линейка для измерения сложности. Что-то совсем простое = 1, что-то сложное = 13. Это относительна шкала, поэтому у всех она своя. Оценки в SP эмпирические, то есть основанные на предыдущем опыте. Если что-то не понятно во сколько оценить, то нужно это разбить на кусочки и каждый оценить в отдельности.

2. У разработчиков есть такая же проблема, обсудите с ними. Она называется "технический долг". Каждое изменение в функциональности требует переписывания чего-то ранее написанного. Эта как-бы лишняя работа крадет время и снижает скорость команды. Очевидно, что с этим нужно бороться.

Я знаю два подхода, которые здесь можно применить:

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

б) Непрерывно улучшать дизайн (кода и тестов) с той целью, чтобы поддержка новых историй не требовала много времени. Это уже только в руках разработчика/тестировщика - делать гибкий дизайн. Банальный пример, в автоматических тестах привязываться не к названиям, и не расположению их внутри модели UI, а только к ИД элементам интерфейса.

Описанной проблемы не существует. Функции contains плевать на переводы строки. Также это выражение вполне вычисляется.

Ну так этим конструктором ты затыкаешь ему рот, а нужно принимать строку и передавать ее предку:

incorrect_header_format() : std::runtime_error("Invalid header") {}

Далее при использовании исключения incorrect_header_format передавай имя файла в конструктор, ровно так как ты это делаешь здесь:
throw std::runtime_error( msg.str() ); // (3)

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