Для розеток так и есть, в каждое помещение своя группа и для некоторых приборов отдельная (например, холодильник для режима «отпуск» или проточный водонагреватель на 9 кВт). По свету объемнее, классическая звезда – к каждой группе свой силовой и свой управляющий кабель. От реле в подрозетниках решил уйти по нескольким причинам: доп. точки отказа и просто дороже в каждый выключатель ставить реле. Да, сейчас точек отказа меньше, если выйдет из строя блок реле, то сразу несколько групп света откажут. Но это реле быстро меняется, а группы света помещений распределены между разными блоками, чтобы при отказе одного без света не осталась вся комната. А при проектировании старался все уместить именно в щите, а не на конечных точках, чтобы обслуживать все в одном месте.
Для каждого по мощения своя группа розеток, освещение по топологии звезда, отдельно мокрые зоны, мощные потребители и так выходит силовой щит на 54 модуля, плюс щит автоматики на 54 (с небольшим запасом на масштабирование)
Да, написать изолированный кусок кода для одной функции — это сейчас идеальная задача для любой LLM.
Но тут есть пара нюансов:
Проблема микросервисов никогда не была в написании кода одного сервиса. Главная боль — это распределенные транзакции, разрыв сети, консистентность данных и распределенный трейсинг. LLM еще очень плохо понимают архитектуру всей системы целиком и то, как эти 50 «идеально написанных» кусочков будут общаться между собой в проде под нагрузкой.
Если сейчас больно искать, где потерялся спан в трейсе из десятка сервисов, написанных людьми, то представьте, каково будет дебажить логику, которую нагенерили агенты без единого архитектурного видения.
Учитывая, что у новых моделей окна контекста уже пробивают 1-2 миллиона токенов, ограничение «маленького контекста» — это временно (хочется в это верить). Скоро скормить LLM-ке хорошо структурированный модульный монолит будет даже выгоднее: она будет видеть всю предметную область разом, а не пытаться угадать контракты соседнего сервиса.
Так что, с точки зрения написания — да, проще. А вот с точки зрения поддержки всей инфраструктуры — LLM могут этот «налог на микросервисы» только увеличить, генерируя их десятками там, где хватило бы одного модуля.
И мечты бьются о суровую выборку... Рынок так долго премировал за знание «модно-молодёжных» технологий, что найти того, кто понимает, почему один JOIN лучше десяти сетевых вызовов, сегодня труднее, чем архитектора с сертификатом AWS.
Немного выше @Wesha открыл хорошую коробочку, рекомендую посмотреть.
А если коротко от себя:
Санировать ввод - прекрасная мысль. А вот захардкодить в схему БД ограничение «только Россия и только 10 цифр» – это классический legacy-капкан.
Ваше решение намертво привязывает бизнес к одной стране. Что произойдет, когда к вам придет клиент из Беларуси (+375) или Узбекистана (+998)? База с ограничением в 10 символов просто не даст ему зарегистрироваться.
Да и любой адекватный SMS-шлюз работает по международному стандарту E.164 (до 15 цифр, начиная с +). Если вы отрезали код страны, вам придется хардкодить +7 обратно при каждом обращении к API провайдера.
Здравствуйте! Отличный рефлекс – думать о защите ПДн. Но остаются проблемы:
При утечке БД такой алгоритм разгадают за 5 минут, и от штрафов регуляторов (например, по 152-ФЗ) это самописное решение не спасет. Нужна реальная криптография, а там в любом случае необходимо хранить строку (могу ошибаться, в криптографии не силен).
Ваш кейс идеально подтверждает статью: вы выбрали INT именно ради математики, и это сразу всё сломало. 0306 + 1111 = 1417, а 306 + 111 = 417. Без отдельного хранения длины ключа вы не сможете расшифровать данные обратно. И тут начинается усложнение.
Что делать при переполнении разрядов с серией 0999? 999 + 1111 = 2110.
Представления отличный инструмент. Но зачем изначально создавать себе проблему на уровне хранения (терять данные), чтобы потом героически её решать через View? База должна хранить консистентные факты.
Что касается изменения форматов в будущем: если МВД добавит пятую цифру, букву или дефис, тип CHAR или VARCHAR мигрировать/расширить гораздо проще. А вот если вы заложились на INTEGER, то при появлении букв ваша схема просто ляжет с ошибкой типизации.
Единственный "исход", который я ожидаю – что разработчик умеет думать о природе данных.
Расскажите, в каком таком контексте потеря данных (ведущего нуля) – это не баг, а допустимый недостаток, у которого есть свои "преимущества"? Экономия 2 байт на жестком диске в обмен на невалидные паспорта пользователей? Отличный трейд-офф, заверните два.
Вы предлагаете классический антипаттерн – размазать ответственность за целостность данных тонким слоем по фронтенду или бизнес-логике. База данных должна хранить сам факт (идентификатор), а не математическую абстракцию, которую нужно каждый раз "собирать" костылями.
Представьте: завтра к этой базе подключается новый микросервис, BI-система для аналитики или понадобится сырая выгрузка в CSV. Каждому новому клиенту придется заново писать этот костыль с подстановкой нулей. А если кто-то забудет это сделать? Данные разъедутся. База должна гарантировать консистентность: положили строку – достали строку.
Спасибо за перевод и очень точный диагноз! Особенно мысль о том, что ИИ просто подсветит тех, кто не умеет «водить эту штуку».
Я в своей книге как раз препарирую этот феномен. Индустрия годами поощряла разработчиков собирать продукты из готовых черных ящиков ради быстрого Time-to-Market. Выросло целое поколение специалистов, которые виртуозно перекладывают JSON из одного API в другое, но совершенно не понимают, как работает память, сеть и железо под капотом. Именно их и заменит ИИ. Потому что нейросеть уже сейчас перекладывает формочки и пишет бойлерплейт дешевле и быстрее. А вот для инженеров, которые умеют считать байты, понимают цену абстракций и строят архитектуру, ИИ станет просто экскаватором вместо лопаты. Пропасть станет огромной.
Вы очень точно подметили про "иллюзию простоты". Никто не призывает возвращаться к ручному управлению памятью везде и всюду, но вот эта потеря связи между "написал строчку" и "понял, что произошло под капотом" действительно пугает. Рад, что мы на одной волне!
Секрет в том, что бизнесу (или "кабанычу") не нужно продавать "красивую архитектуру". Ему нужно продавать метрики и деньги. Если фича, написанная за 1 день, заставляет приложение тормозить на бюджетных Android-смартфонах, конверсия падает, и бизнес теряет деньги. Плюс, не отдавать на фронт всю таблицу из БД вместе с техническими и неиспользуемыми на клиенте полями – это не N дней работы, это просто грамотно написанный DTO/сериализатор, который пишется за те же 15 минут, но экономит мегабайты.
Именно) JSON – прекрасный инструмент. Формат ни в чем не виноват. Виновато отношение, при котором "раз это текст и он гибкий, значит можно запихивать в него вообще всё подряд без разбора, фронтенд сам отфильтрует". Об этом и речь.
Микрооптимизации и переписывание на Rust ради 5мс без бизнес-цели – это зло. Но в статье речь не о преждевременной оптимизации, а о базовой инженерной гигиене. Спроектировать API так, чтобы он не отдавал клиенту пароли, внутренние ID базы и лишние 50 полей, которые не используются на экране – это не "наворот", это нормальный дизайн. Чинить это потом, когда база ляжет от рекурсивных джойнов, а клиенты начнут жаловаться на лаги – обойдется бизнесу в десятки раз дороже.
А если бы с нуля делали проводку, как бы реализовали?
Да
Есть такой риск, но пошел на него осознанно. На бойлер не хочется тратить место. А водогрей нужен только на период летних отключений.
Для розеток так и есть, в каждое помещение своя группа и для некоторых приборов отдельная (например, холодильник для режима «отпуск» или проточный водонагреватель на 9 кВт). По свету объемнее, классическая звезда – к каждой группе свой силовой и свой управляющий кабель. От реле в подрозетниках решил уйти по нескольким причинам: доп. точки отказа и просто дороже в каждый выключатель ставить реле. Да, сейчас точек отказа меньше, если выйдет из строя блок реле, то сразу несколько групп света откажут. Но это реле быстро меняется, а группы света помещений распределены между разными блоками, чтобы при отказе одного без света не осталась вся комната.
А при проектировании старался все уместить именно в щите, а не на конечных точках, чтобы обслуживать все в одном месте.
Для каждого по мощения своя группа розеток, освещение по топологии звезда, отдельно мокрые зоны, мощные потребители и так выходит силовой щит на 54 модуля, плюс щит автоматики на 54 (с небольшим запасом на масштабирование)
Нет, диф. автомат только один есть для холодильника. Для всего остального связка УЗО + автоматы
Или один проточный водонагреватель
Да, написать изолированный кусок кода для одной функции — это сейчас идеальная задача для любой LLM.
Но тут есть пара нюансов:
Проблема микросервисов никогда не была в написании кода одного сервиса. Главная боль — это распределенные транзакции, разрыв сети, консистентность данных и распределенный трейсинг. LLM еще очень плохо понимают архитектуру всей системы целиком и то, как эти 50 «идеально написанных» кусочков будут общаться между собой в проде под нагрузкой.
Если сейчас больно искать, где потерялся спан в трейсе из десятка сервисов, написанных людьми, то представьте, каково будет дебажить логику, которую нагенерили агенты без единого архитектурного видения.
Учитывая, что у новых моделей окна контекста уже пробивают 1-2 миллиона токенов, ограничение «маленького контекста» — это временно (хочется в это верить). Скоро скормить LLM-ке хорошо структурированный модульный монолит будет даже выгоднее: она будет видеть всю предметную область разом, а не пытаться угадать контракты соседнего сервиса.
Так что, с точки зрения написания — да, проще. А вот с точки зрения поддержки всей инфраструктуры — LLM могут этот «налог на микросервисы» только увеличить, генерируя их десятками там, где хватило бы одного модуля.
И мечты бьются о суровую выборку... Рынок так долго премировал за знание «модно-молодёжных» технологий, что найти того, кто понимает, почему один JOIN лучше десяти сетевых вызовов, сегодня труднее, чем архитектора с сертификатом AWS.
Немного выше @Wesha открыл хорошую коробочку, рекомендую посмотреть.
А если коротко от себя:
Санировать ввод - прекрасная мысль. А вот захардкодить в схему БД ограничение «только Россия и только 10 цифр» – это классический legacy-капкан.
Ваше решение намертво привязывает бизнес к одной стране. Что произойдет, когда к вам придет клиент из Беларуси (+375) или Узбекистана (+998)? База с ограничением в 10 символов просто не даст ему зарегистрироваться.
Да и любой адекватный SMS-шлюз работает по международному стандарту E.164 (до 15 цифр, начиная с +). Если вы отрезали код страны, вам придется хардкодить +7 обратно при каждом обращении к API провайдера.
Здравствуйте! Отличный рефлекс – думать о защите ПДн. Но остаются проблемы:
При утечке БД такой алгоритм разгадают за 5 минут, и от штрафов регуляторов (например, по 152-ФЗ) это самописное решение не спасет. Нужна реальная криптография, а там в любом случае необходимо хранить строку (могу ошибаться, в криптографии не силен).
Ваш кейс идеально подтверждает статью: вы выбрали INT именно ради математики, и это сразу всё сломало. 0306 + 1111 = 1417, а 306 + 111 = 417. Без отдельного хранения длины ключа вы не сможете расшифровать данные обратно. И тут начинается усложнение.
Что делать при переполнении разрядов с серией 0999? 999 + 1111 = 2110.
Представления отличный инструмент. Но зачем изначально создавать себе проблему на уровне хранения (терять данные), чтобы потом героически её решать через View? База должна хранить консистентные факты.
Что касается изменения форматов в будущем: если МВД добавит пятую цифру, букву или дефис, тип CHAR или VARCHAR мигрировать/расширить гораздо проще. А вот если вы заложились на INTEGER, то при появлении букв ваша схема просто ляжет с ошибкой типизации.
Отличное дополнение про иностранные и советские паспорта (возьму на вооружение в качестве дополнения, вопрос все же про паспорта РФ).
Это как раз тот самый «контрольный выстрел» в архитектуру, построенную на INTEGER.
Единственный "исход", который я ожидаю – что разработчик умеет думать о природе данных.
Расскажите, в каком таком контексте потеря данных (ведущего нуля) – это не баг, а допустимый недостаток, у которого есть свои "преимущества"? Экономия 2 байт на жестком диске в обмен на невалидные паспорта пользователей? Отличный трейд-офф, заверните два.
Вы предлагаете классический антипаттерн – размазать ответственность за целостность данных тонким слоем по фронтенду или бизнес-логике. База данных должна хранить сам факт (идентификатор), а не математическую абстракцию, которую нужно каждый раз "собирать" костылями.
Представьте: завтра к этой базе подключается новый микросервис, BI-система для аналитики или понадобится сырая выгрузка в CSV. Каждому новому клиенту придется заново писать этот костыль с подстановкой нулей. А если кто-то забудет это сделать? Данные разъедутся. База должна гарантировать консистентность: положили строку – достали строку.
Спасибо за перевод и очень точный диагноз! Особенно мысль о том, что ИИ просто подсветит тех, кто не умеет «водить эту штуку».
Я в своей книге как раз препарирую этот феномен. Индустрия годами поощряла разработчиков собирать продукты из готовых черных ящиков ради быстрого Time-to-Market. Выросло целое поколение специалистов, которые виртуозно перекладывают JSON из одного API в другое, но совершенно не понимают, как работает память, сеть и железо под капотом. Именно их и заменит ИИ. Потому что нейросеть уже сейчас перекладывает формочки и пишет бойлерплейт дешевле и быстрее. А вот для инженеров, которые умеют считать байты, понимают цену абстракций и строят архитектуру, ИИ станет просто экскаватором вместо лопаты. Пропасть станет огромной.
Вы очень точно подметили про "иллюзию простоты". Никто не призывает возвращаться к ручному управлению памятью везде и всюду, но вот эта потеря связи между "написал строчку" и "понял, что произошло под капотом" действительно пугает. Рад, что мы на одной волне!
Секрет в том, что бизнесу (или "кабанычу") не нужно продавать "красивую архитектуру". Ему нужно продавать метрики и деньги. Если фича, написанная за 1 день, заставляет приложение тормозить на бюджетных Android-смартфонах, конверсия падает, и бизнес теряет деньги. Плюс, не отдавать на фронт всю таблицу из БД вместе с техническими и неиспользуемыми на клиенте полями – это не N дней работы, это просто грамотно написанный DTO/сериализатор, который пишется за те же 15 минут, но экономит мегабайты.
Именно) JSON – прекрасный инструмент. Формат ни в чем не виноват. Виновато отношение, при котором "раз это текст и он гибкий, значит можно запихивать в него вообще всё подряд без разбора, фронтенд сам отфильтрует". Об этом и речь.
Микрооптимизации и переписывание на Rust ради 5мс без бизнес-цели – это зло. Но в статье речь не о преждевременной оптимизации, а о базовой инженерной гигиене. Спроектировать API так, чтобы он не отдавал клиенту пароли, внутренние ID базы и лишние 50 полей, которые не используются на экране – это не "наворот", это нормальный дизайн. Чинить это потом, когда база ляжет от рекурсивных джойнов, а клиенты начнут жаловаться на лаги – обойдется бизнесу в десятки раз дороже.