Все потоки

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

Двигатель с постоянными магнитами на поверхности ротора (SPMSM) – прост и предсказуем. Магнитный зазор равномерен, индуктивности по обеим осям одинаковы, момент создаётся единственным способом. Управлять им несложно.

Двигатель с интерполированными постоянными магнитами IPMSM (Interior Permanent Magnet Synchronous Motor) – устроен принципиально иначе. Магниты утоплены в тело ротора, что нарушает симметрию магнитной цепи. Возникает анизотропия: магнитное сопротивление ротора различается по двум взаимно перпендикулярным направлениям. Следствие – дополнительный источник момента, реактивный, существующий исключительно за счёт разницы индуктивностей по осям d и q.

Именно эта анизотропия делает IPMSM привлекательным для тягового привода. Широкий диапазон ослабления поля, высокая удельная мощность, возможность использовать реактивный момент для снижения токовой нагрузки – всё это следствие одного конструктивного решения: магниты внутри, а не снаружи.

Реализовать потенциал IPMSM позволяет стратегия MTPA – Maximum Torque Per Ampere. Она находит оптимальное распределение вектора тока статора между осями d и q: такое, при котором заданный момент достигается при минимальной амплитуде тока. Меньший ток – меньше потерь в меди, меньше нагрев, меньше нагрузка на инвертор.

В настоящей статье рассматривается физика анизотропии IPMSM, математическая модель машины в системе координат d-q и стратегия MTPA как задача оптимизации с аналитическим решением. Модель реализована в системе моделирования Engee и верифицирована сравнением режимов FOC и MTPA на параметрах макетного образца IPMSM.

Чтобы интегрировать ИИ в процессы, российскому бизнесу нужен провайдер API, который сможет заключить официальный договор и принять оплату рублями. Как такого найти и подключить и что это даёт бизнесу?

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

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

Список «хочу прочитать» давно перевалил за сотню. Когда наконец добираешься до книги — появляется другая проблема: хочется зафиксировать цитату или мысль, но непонятно куда. Заметки в телефоне, вкладка в браузере, стикер на полях — через месяц это всё теряется. Обычный подход «одна заметка на книгу» не работал: либо файл разрастался до неприличия, либо я просто забывал его открывать. Тогда я перестал искать «правильный» плагин и спроектировал систему с нуля в Obsidian. В этой статье я покажу архитектуру, реальные шаблоны и конфигурацию баз данных — так, чтобы это можно было повторить.

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

TL;DR: Sentry дедуплицирует backend-ошибки по хешу (error class + top stack frame + module). Для UI-багов этот рецепт ломается — у expect(button).toBeVisible() нет stack frame в продуктовом смысле, есть локатор + assertion + URL. В webtest-orch я собрал composite SHA-256 fingerprint из (normalized_selector | assertion type | error class | URL template | message[:80]) с тремя rules нормализации (:nth-child, UUID, /users/123 → /users/:id). Это даёт стабильный 8-hex BUG-id который выживает прогоны и даёт diff new / regression / persisting / fixed без БД и embedding’ов.

Есть ли у нас в компании психологическая безопасность? Конечно!

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

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

Меньше недели назад (30 апреля) в Steam и Microsoft Store стартовал ранний доступ к новой главе легендарной серии - Heroes of Might and Magic: Olden Era. После более чем десятилетнего ожидания фанаты наконец‑то получили возможность погрузиться в мир, где вновь правят герои, магия и полководческие решения на пошаговой карте. Судя по первым дням в Steam, стратегия встречена с воодушевлением: более 90% положительных оценок в первые сутки и рекордный онлайн для серии в раннем доступе.

Давайте разберём, что в действительности говорят игроки о Olden Era и почему новинку уже возводят в ранг «великого возвращения».

С вами Глеб из Plati.Market, подтягиваем олдскулы и утираем слёзы ностальгии, погнали.

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

Пространство вокруг нас на первый взгляд кажется трехмерным. Так ли это на самом деле? Вооружаемся логикой, скептицизмом, дедукцией и включаем наш мыслительный аппарат — поехали!

Как Rust обманывает процессор. Часть 2: niche сквозь крейты, dropck, Pin и провенанс указателей

В первой части мы обсуждали niche-оптимизацию, drop flags, MIR, Stacked Borrows и async-стейт-машины. В комментариях справедливо заметили (спасибо, Mingun): про niche рассказано в простой форме - Option<&T> и NonZeroU8.

А что происходит, когда enum живёт в одном крейте, оборачивается в newtype в другом, и оба варианта внешнего enum хранят один и тот же внутренний? У такого внешнего типа всего четыре состояния, байта должно хватить. Хватит ли? Зависит от того, как rustc считает layout. Об этом и поговорим.

Во второй части идём глубже: niche сквозь границы крейтов, variance, Pin и самоссылающиеся футуры, dropck с #[may_dangle], Tree Borrows вместо Stacked Borrows и strict provenance. Без этого половина unsafe-кода в экосистеме держится на честном слове.

Kubernetes давно стал повсеместной платформой, а написать к нему собственный оператор сегодня — задача нескольких часов. Стандартный путь — kubebuilder на основе controller-runtime: scaffold проекта, типы, реконсайлер. В типовых сценариях этого вполне достаточно. Но как только нагрузка растёт или поведение оператора начинает расходиться с ожиданиями, всплывает целый класс edge-кейсов, причина которых — непонимание того, как controller-runtime устроен внутри. Если вы пишете контроллеры для Kubernetes, этот материал поможет собрать целостную mental model и заранее избежать дорогих сюрпризов в проде.

В этой статье разберём внутреннее устройство controller-runtime и на его примере увидим, какие архитектурные решения лежат в основе самого Kubernetes. Начнём с того, как контроллеры читают объекты из Kubernetes API.

Есть распространённое заблуждение, что r.Get() в Reconcile ходит прямо в kube-apiserver, List() каждый раз смотрит «живую» картину мира, а после Update() можно сразу перечитать объект и увидеть свежее состояние. На практике всё наоборот: controller-runtime живёт на локальной копии данных через LIST+WATCH. Благодаря этому чтение в реконсайле обходится почти бесплатно и не нагружает control plane даже при сотнях вызовов в секунду — но ценой этой модели становится то, что оператор может внезапно съедать гигабайты памяти, делать скрытые O(n)-сканы и регулярно упираться в stale reads.

Статья рассчитана на тех, кто уже писал операторы на Go с использованием controller-runtime, но хочет собрать целостную mental model, а не жить с набором частных наблюдений. Фокус будет на практических последствиях для production-кластеров: память, трафик, консистентность чтения и поведение реконсайла.

"Деврел-супервизия" делалась для тех, кому нужен разговор в профессиональном контексте на поныть и послушать, а как жить дальше. «Зачем сейчас деврел инженерам», «не вижу роста», стыдно нести свои маленькие сомнения и проблемы на платный менторинг, а выговориться хочется по-взрослому.

Собрали 8 экспертов, которые разбираются в кризисах: от опытных деврелов до специалистов по выгоранию в ИТ и карьерному консультированию.

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

Тема первая: как справляться с возрастными и статусными сомнениями, будучи линейным специалистом старше части команды и руководителей?

Неделю назад я не думала, что буду писать базу данных. Начиналось всё с банального «хочу строчку в резюме». А получилось: LSM‑дерево, MVCC, снапшоты, Value Log, WAL, компакшн, Column Families и даже GC. Всё на чистом Go, без cgo. Плюс gRPC, REST, CLI и Docker из коробки.

Рассказываю, как собирала конструктор, где наступала на грабли и почему fsync — это боль, и в конце даже небольшая любовная драма в CLI

Всем привет!

🏋️ Боли в спине — профессиональная болячка разработчиков.

Я тоже прошёл через это и делюсь своей зарядкой. Делаю её 2 раза в неделю — это помогает, спина не болит.

В этой статье мы расскажем, как сократили время на поиск информации в корпоративной базе знаний и превратили тысячи страниц документации в удобного ИИ-ассистента. А также поделимся, как реализовали локальный GPT, почему выбрали путь собственных решений вместо готовых сервисов, с какими инфраструктурными вызовами столкнулись и как в итоге собрали рабочие инструменты на базе self-hosted-версии low-code-платформы n8n, полностью закрыв данные внутри корпоративного контура.

Хотя о технологиях 5G написано немало, зачастую в статьях упускают важный аспект: как эволюция сетей влияет на архитектуру решений и требования к телеком‑инфраструктуре. Компания Nexign активно адаптирует свои продукты под новые вызовы. В этой статье Илья Новоселов, руководитель бизнес‑направления по телеком‑решениям, подробно разберёт архитектуру сети 5G. Начнем с верхнеуровневого знакомства с принципами, интерфейсами и моделями обмена информацией.

Большинство экспериментов с AI в юридической сфере упираются в одну и ту же проблему: LLM умеет красиво отвечать, но теряется, как только появляется контекст компании, история согласований, шаблоны договоров и внутренние регламенты.

В статье разбираем, почему обычный чат‑бот плохо подходит для таких задач, как устроен AI‑агент с памятью и доступом к документам, и как собрать рабочую систему на базе Cursor, md‑файлов и базы знаний, которая действительно помогает анализировать договоры, а не генерирует очередной список общих рекомендаций.

Год с Claude Code: как собрать рабочую конфигурацию с первого запуска

Жемал Хамидун, Head of AI Alpina Digital, CPO AlpinaGPT, автор тг-канала "Готовим ИИшницу"