Привет, меня зовут Тимофей. Я программист. Не электрик и не электронщик. А человек, который хочет, чтобы дома свет включался сам, батареи не грели зря, а домофон говорил голосом, кто к нам пришел. Для этого у меня есть лишь бытовые навыки уровня «поменять розетку» и понимание, как писать код для компьютеров (это помогает, но как оказалось - это не ключевое: код для умного дома почти не пишу).

Когда-то в детстве мы с папой собрали простенькую схему на конденсаторе: открываешь дверь — включается свет и горит около минуты. Тогда это казалось магией. Спустя много лет я решил повторить эту магию, но уже в масштабах своей квартиры. И понеслось…

Сначала были простые «коробочные» беспроводные решения: Z-Wave, ZigBee, Wi-Fi. Потом — кабели, щитки, Modbus, Wiren Board, Sprut.Hub. В какой-то момент автоматизация опутала весь дом: от света в туалете до пылесоса и бризера. И при этом я старался, чтобы все работало надежно, не зависело от облаков и не вызывало неприятия у семьи (ну… почти всегда).

Эта статья — мой личный путь. С ошибками, переделками, удачными находками и местами, где «так нельзя, но работает». Возможно, вы найдете тут интересные идеи, которые работают каждый день, а не только хорошо выглядят на красивых презентациях.

Когда работаешь по 16 часов за компьютером, стол перестаёт быть мебелью и превращается в инструмент. Этим инструментом я и занялся. И вот что из этого вышло

Привет, Хабр!

Иногда кажется, что команда вроде бы стабильная, спринты идут по плану — а под конец снова в панике жмёмся к дедлайну, выкидываем фичи и дорабатываем вечерами. Чтобы такого не происходило, я хочу рассказать про простую и очень рабочую модель — 3–3–3. Она помогает прогнозировать скорость команды без гаданий на story points и держать реалистичный фокус: сколько мы реально успеем, а не сколько хочется.

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

В этой статье не будет примеров кода и конкретных архитектурных приёмов. Но если, читая книги и статьи по Domain Driven Design, вы недоумеваете «зачем это всё вообще», возможно, у меня есть для вас ответ. Правда, боюсь, что он вам не особо понравится.

Разработчики всё чаще полагаются на ИИ-помощников, чтобы ускорить повседневную работу с кодом. Эти инструменты умеют автозаполнять функции, предлагать исправления ошибок и даже генерировать целые модули или MVP. Тем не менее, как многие из нас убедились, качество вывода ИИ во многом зависит от качества предоставленного запроса. Плохо сформулированный промпт может привести к нерелевантным или общим ответам, в то время как хорошо составленный — дать продуманные, точные и даже креативные решения для кода.

Под катом Эдди Османи, ведущий инженер Google, выделяет ключевые шаблоны запросов, повторяемые фреймворки и запоминающиеся примеры, которые нашли отклик у разработчиков.

Автор приводит параллельные сравнения хороших и плохих промптов, фактические ответы ИИ, а также комментарии: чтобы понять, почему один запрос успешен, а другой терпит неудачу.

Вы «должны» проводить 1-on-1.
А зачем?

Знаете, зачем они нужны — по-настоящему?
Или пробовали, но всё свелось к «ну, как дела?»
Может быть, встречи идут — но ничего не меняется?

Что ж, давайте разбираться:

Привет, Хабр! Меня зовут Никита, я занимаюсь iOS-разработкой в Яндекс Диске. Как вы знаете, прошлой осенью зарелизился Swift 6, а вместе c ним появились и строгие проверки для защиты от датарейсов, связанные со Swift Concurrency.

В этой статье я постараюсь разобраться с основными изменениями в каждом пропозале и поделюсь своими заметками, тем, что мне показалось самым важным или интересным. В конце статьи бонус — Playground с тестами для каждого пропозала, чтобы можно было поиграть с кодом, детальнее разобраться с изменениями и понять, как они влияют на код, написанный на Swift 5.

Мы продолжаем посещать проекты разных интеграторов и натолкнулись на интересный случай. Заказчик в Подмосковье — серьезный человек, не айтишник, к умным домам относится скептически.

Сначала он хотел сделать только автоматизацию котельной и ландшафтное освещение по расписанию. И даже разочаровался в интеграторе и сменил на другого. Новый интегратор заговорил на понятном ему языке и смог изменить мнение заказчика.

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

В марте этого года я написал статью о датчике присутствия на сенсоре LD-2410. Он вполне себе пошел в массы и с учетом пожеланий пользователей я стал его дорабатывать.

Привет, меня зовут Андрей Кузьминых. Я технологический предприниматель, запускаю ИИ-стартапы и внедряю искусственный интеллект в компаниях. Некоторое время назад я работал в Сбере в роли директора по данным и ИИ, где мы с командой анализировали огромные массивы данных, строили ML-модели, создавали управленческие дашборды и рекомендательные сервисы. Но одним из самых интересных и нестандартных проектов стало создание первого в России корпоративного приложения для знакомств среди сотрудников – SberDating. Идея родилась из стремления помочь людям найти тех, с кем можно установить нечто большее, чем просто деловые отношения, – друзей, собеседников, а возможно, и любимого человека. Но чтобы понять, как мы к этому пришли, нужно вернуться на пять лет назад.

Если вам интересна тема ИИ, мои кейсы и опыт, подписывайтесь на мой телеграм-канал, где я делюсь инсайтами, практическими советами и последними новостями из мира искусственного интеллекта.

Рассказываю, как я начинаю превращать в «умный дом» своё пространство в только что сданной бетонной многоэтажке-новостройке, где нет ни раковины, ни других атрибутов цивилизации, и где я их пока даже не планирую.

Последнюю пару лет я живу с приточной вентиляцией в городской квартире — и очень рад этому факту.

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

Коротко о главном:
• наружное расположение компонентов ради минимального уровня шума;
• минимум ручного труда в изготовлении и монтаже;
• общий ценник существенно ниже 50 тысяч рублей (ниже 30 тысяч — на момент изготовления два года назад).

И важное. Если вы — адепт систем рекуперации, долгих инженерных расчётов и полугода проектирования, эта статья не для вас. Я — адепт золотой середины между «я сделяль» и «я задолбался».

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

Недавно к нам обратился энтузиаст Андрей из Петербурга. Сначала он сделал свой умный дом, затем собрал команду специалистов и стал интегратором. Бюджет его собственного проекта впечатляет — 11 миллионов рублей — и это только на автоматизацию!

Давайте узнаем, какие возможности предлагает такой умный дом и чем Андрей может нас удивить.

В статье расскажу как можно отправлять текущую температуру с внешнего датчика кондиционеру и как можно управлять обычным кондиционером через умный дом с помощью ESPHome и HomeAssistant.

В этой статье я бы хотел рассказать о том, как можно управлять умным домом и всеми устройствами (не только Zigbee) в Home Assistant даже без подключения к интернету.

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

В статье описывается оптимальный архитектурный шаблон большого iOS-приложения на Swift, выступающего преимущественно тонким клиентом. Основной упор делается на применение чистой архитектуры. Статья предназначается как новичкам, так и опытным программистам. Для удобства навигации имеется оглавление.

Всем привет! Хочу рассказать о небольшом и довольно простом кейсе использования Home Assistant, но на мой взгляд очень полезном. Это контроль ресурса магистральных фильтров. Идея сделать что то такое беспокоила меня давно и вот наконец руки дошли и до этого.

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

И все это дельные советы, ничего плохого в них нет, но хочется чего то большего.