Все потоки

Рассматривая любительские рукодельные электронные лампы, например, [1, 2], интересно и полезно будет вспомнить и об остальных радиоэлементах, изготовлять которые ранним любителям приходилось самостоятельно и собственноручно. Кроме естественных корпусов-ящиков и контурных катушек, дросселей, трансформаторов, коллеги-предки часто были вынуждены делать и почти всё остальное — как установочные элементы — ручки, верньеры, шкалы, клеммы, включатели-переключатели, ламповые панельки, так и радиоэлементы пассивные — резисторы и конденсаторы переменные и постоянные, диоды (детекторы и выпрямители), элементы питания, в том числе и анодные (а это на минуточку — 40…80 вольт!) батареи.

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

Если вы уже разобрались с классическими сообщениями LayerZero (push-модель: отправили сообщение из одной сети и получили в другой сети), следующий шаг — научиться читать состояние других сетей, не разворачивая там свои контракты и не гоняя туда-сюда два сообщения. Для этого в LayerZero v2 есть lzRead — это request–response (pull) паттерн: контракт в исходной сети отправляет запрос (lzSend), а ответ возвращается обратно в исходную сеть и обрабатывается в lzReceive.

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

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

Мысль была такая:

волшебная палочка — это очень плохо спроектированный интерфейс.

Если посмотреть на неё не как на магический артефакт из сказок, а как на устройство взаимодействия пользователя с системой, то получается довольно странная конструкция.

Причём странная почти по всем параметрам: от физического дизайна до модели управления.

Попробуем разобрать её как обычное инженерное устройство.

Российский рынок CRM заметно «расслоился» на два мира. Первый — массовые «коробочные» решения для малого и среднего бизнеса с быстрым стартом и относительно жёсткими сценариями. Второй — корпоративные CRM‑платформы, которые выбирают крупные компании: с длительным циклом сделки, сложной организационной структурой, кросс‑функциональными процессами, требованиями по интеграциям, безопасности и высокой нагрузке.

В этом материале я решил сделать обзор корпоративных CRM-платформ, способных оказать комплексный эффект на весь бизнес — не только на воронку продаж. Разобраться в особенностях каждой из них бывает непросто, и я надеюсь вам в этом помочь!

Сегодняшняя статья основана на полугодовом опыте глубокого использования Claude Code и кучи набитых шишек. Надеюсь, это будет полезно.

Поначалу я использовал его как обычный чат-бот, но довольно быстро понял, что что-то идёт не так: контекст становился всё более хаотичным, инструментов становилось всё больше, но эффективность только падала, правила становились всё длиннее, но соблюдались всё реже. После некоторого времени ковыряния и изучения самого Claude Code я осознал – это не проблема промптов, а особенность архитектуры самой системы.

В этой статье я хочу обсудить несколько вещей: как Claude Code работает изнутри, почему контекст засоряется и как с этим бороться, как правильно проектировать Skills и Hooks, как правильно использовать Subagents, как архитектура Prompt Caching влияет на всё, и как написать действительно полезный CLAUDE.md.

Меня зовут Илья, я мобильный разработчик в Naumen. Моя основная специализация — iOS-разработка. Я занимаюсь развитием мобильного клиента платформы Naumen Service Management Platform, а также Chat SDK в рамках Naumen Contact Center.

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

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

Привет, Хабр! Меня зовут Елизавета, я скрам-мастер стрима ДБО (веб-версия дистанционного банковского обслуживания) для банков в команде РСХБ.Цифра. Выстраиваю процессы на основе человекоцентричного подхода, помогаю команде раскрывать потенциал. В этом материале хочу поделиться с вами историей о том, как мы превратили обычную задачу по формированию команд в приятный процесс. Да, это возможно! Расскажу не только о методиках, но и человеческих взаимоотношениях, где психология — лучший друг программистов и тимлидов, которые объединяются ради создания продукта в финтехе.

Мы едим хлеб, а не смотрим на замешивание теста

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

Мы должны руководствоваться достижением цели, а не удобством процессов.

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

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

Как руководитель отдела ИИ с опытом внедрения решений в холдингах на 15 000+ сотрудников, я вижу, что только системный инженерный подход спасает проекты от превращения в «дорогой гараж».

Всем привет! Это мой первый опыт в ведение своего личного блога и более того даже в написание статей. Ну попытка не пытка.

В этом посте я честно расскажу о своем пути (от фрилансера до основателя digital студии). Где я ошибался, что помогло вырасти. Также поделюсь кое-какими мыслями, может кому то они будут интересны.

17 марта в Российском новом университете прошёл пресс-завтрак на тему «Гражданские беспилотники: от аэрофотосъёмки до сельского хозяйства». Цель мероприятия была связана с донесением до широких масс через приглашенных журналистов мысли о том, что БПЛА, даже в современных и очень непростых условиях, это отнюдь не только военные коптеры и дроны-разведчики, а средства передвижения и перемещения полезной нагрузки с огромным потенциалом для самых разных сфер и отраслей экономики.

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

Между тем любое подобное вмешательство имеет цену. Оно требует времени, отвлекает людей от основной работы, увеличивает организационные издержки и нередко замедляет движение проекта. Значит, для него должно существовать содержательное основание: почему оно нужно именно здесь, именно сейчас и именно в таком объёме.

Всё началось с принтера. Точнее — с 1700 рублей, типографии на Театральной и фотографии моря в Абхазии. Кадр был невероятный: бирюзовая вода, низкое солнце, плачущие эвкалипты, и такой цвет, что хотелось окунуться в дисплей. Я выбрал баритовую бумагу, хотел потом вставить в рамку. Прождал сорок минут в очереди и... На выходе грязно-голубая лужа.

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

Любое научное исследование зарождается из вопроса, на который необходимо найти ответ. Иногда вопрос кажется сложным и непонятным, особенно для не вовлеченных в науку умов. Бывают и более простые с точки зрения синтаксиса вопросы, которые частенько задают самые любопытные существа на планете — дети. Почему небо синее? Почему вода мокрая? Почему птицы летают? Все эти вопросы кажутся простыми, но ответы на них могут быть совокупностью знаний, скрупулезно собранных на протяжение столетий учеными из самых разных областей, от биологии до физики частиц. Ученые из Мэрилендского университета (Колледж-Парк, США) решили задать очередной «простой» вопрос — как часто у человека происходит флатуленция? А ответ на этот вопрос им помогло их собственное изобретение — умное нижнее белье. Каков принцип работы этого необычного элемента гардероба, какие данные он собирает, и что они могут рассказать о здоровье пользователя? Ответы на эти вопросы мы найдем в докладе ученых.

Приветствую всех!

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

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

Привет, Хабр! Меня зовут Александр, я из Сбера, лидер по автоматизации в Департаменте Сервисы и Безопасности. В тестировании я около 13 лет, и последние лет 10 занимаюсь автоматизацией и её развитием в своём подразделении.

В этой статье расскажу, как с помощью IDE, LLM и RAG‑подхода можно автоматизировать одну из самых рутинных задач автоматизаторов — разработку новых автотестов по ручным сценариям, и при этом сохранять стиль и архитектуру проекта.

Люди негативно реагируют в соцсетях на контент, созданный искусственным интеллектом. Иногда пишут «Бл**** ещё один пост из жпт», как недавно (и совершенно несправедливо) прокомментировали один из репостов в UX Notes. В комментариях в Тредс часто можно встретить предположения, что пост написал ИИ, причём без какой-либо эмоциональной оценки. Негативная коннотация подразумевается авторами и уже ощущается читателями.

Почему?

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

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

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

Поэтому решил поделиться своей насмотренностью на этот счет 👇

В российских проектах НСИ часто выходит далеко за рамки справочников и включает задачи MDM и Data Quality. Разбираемся, чем это отличается от классического RDM и к чему это приводит.

В стремлении завести домашний сервер я заходил далеко. В какой-то момент это был экстремальный вариант с 19-дюймовой стойкой на 24 юнита в кладовке, где жило некоторое количество приличного серверного железа. Увлекательно, шумно и непрактично. Со временем я приходил к мысли, что домашняя инфраструктура должна быть компактной и тихой.

Недавно мне знакомый отдал компьютер, сказав что-то вроде «знаю, ты любишь необычные штуки — забирай, понравится». Так в мои руки попал занятный мини-ПК с полностью пассивным охлаждением и процессором Intel Core i7-4500U. Разумеется, мне захотелось посмотреть внутрь. Детали под катом.

9 марта 2026 года Microsoft выпустила VS Code версии 1.111 — первый стабильный еженедельный релиз. Ведущий инженер Кай Мецель объявил, что финальное тестирование будет «встроено в еженедельный процесс». Каждая новая функция в v1.111 связана с ИИ. Главное нововведение: режим Autopilot, в котором ИИ-агент работает автономно до завершения задачи — сам одобряет вызовы инструментов, сам повторяет попытки при ошибках, сам отвечает на собственные вопросы, чтобы «агент не простаивал в ожидании ответа».

Я пишу код в той или иной IDE с начала 2000-х. Видел, как Eclipse замедлялся до ползания, как IntelliJ поглотил мир Java, как VS Code стал редактором по умолчанию для целого поколения. Это — другое. Это не добавление функции. Это изменение самих отношений между разработчиком и инструментом.