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

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

Поэтому физики берут свинец. Только современный свинец оказывается недостаточно хорош.

И тогда в дело идёт груз римского корабля, который затонул у берегов Сардинии больше двух тысяч лет назад. Часть его свинца в итоге оказывается не в музее, а глубоко под горой Гран‑Сассо, где из древнего металла делают радиационную защиту установки, ищущей процесс, который человечество пока вообще ни разу достоверно не наблюдало.

Самое существенное здесь в том, что это не легенда, придуманная вокруг научного проекта. Именно так всё и произошло.

Можно ли на STM32 реализовать однобитный ADC ?
Причем без использования аппаратного ADC. Так, чтобы GPIO пин читался со строго определенным периодом по команде аппаратного таймера и сохранял значения прочитанных логических уровней в массив.
При этом во время чтения N однобитных семплов должно произойти не более 2х аппаратных прерываний.

Сгенерированная картинка для привлечения внимания. Промпт: «Продемонстрируй, что всё новое — это хорошо забытое старое» (нет)

За последний год инструментов для агентной разработки стало столько, что в них легко потеряться: одни обещают сохранять контекст между сессиями, другие — «понимать» всю кодовую базу целиком, третьи — память, планирование и автономность в одном флаконе. На GitHub каждую неделю появляются репозитории с внушительным (и не всегда честно заработанным) числом звёзд, которые обещают всё и сразу, а на поверку оказываются README-проектами; другие честно работают на демо-репозитории и падают с OOM при первой же встрече с реальным энтерпрайз-проектом — и так далее, список можно продолжать долго.

Осенью прошлого года я пользовался связкой Claude + RooCode + семантический поиск на Ollama, и это был мой основной рабочий инструмент — ровно до того момента, как связка перестала работать (об этом чуть ниже). Я решил полностью пересесть на Claude Code и начал искать замену семантическому индексу, но так её и не нашёл: альтернативы для меня просто не работали — на монолите в 3,5M+ строк они либо индексировались часами, либо требовали отдать код в облако (и заплатить немалую сумму за эмбеддинги!!!), либо поддерживали Ruby, мягко говоря, номинально. В итоге я принял непростое для себя решение сделать собственный инструмент — начав с форка простого движка семантического поиска на Ollama + Qdrant — и, что характерно, сделал: полностью локальный, чтобы ни код, ни его производные (индекс, эмбеддинги, граф вызовов) никуда не уезжали. На сегодняшний день на него ушло больше полугода (и, честно признаюсь, не одна сотня чашек чая).

Начало в статье ERP внедрили. Что дальше?

Термины, используемые в статье

Project-DR ERP Technology Distribution — полное название технологической сборки. В дальнейшем — «технологическая сборка Project-DR ERP», версия.

Project-DR — Project Digital Replica, проектная цифровая реплика — внутренняя производственная технология и проектная среда, в которой строится и при необходимости структурно перестраивается профессиональная модель предприятия. Заказчику Project-DR как технологическая среда не передаётся.

Project Core — проектное ядро — проектный носитель специализированного ресурса, в котором хранится подробный результат его работы по конкретному проекту.

Unified Project Store — единое проектное хранилище — машиночитаемый слой Project-DR, в котором собираются принятые проекции результатов специализированных Project Core.

Enterprise-DR — Enterprise Digital Replica, цифровая реплика предприятия — эксплуатационная машиночитаемая модель конкретного предприятия, полученная из принятого состояния Project-DR. Именно Enterprise-DR передаётся заказчику.

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

Enterprise-DR Runtime Kit — комплект, передаваемый заказчику для развёртывания и эксплуатации Enterprise-DR.

PostgreSQL — система управления базами данных, используемая в версии 2.5.1 как эталонная реализация базы Enterprise-DR. Далее — «база Enterprise-DR».

Enterprise-DR API — программный интерфейс доступа к эксплуатационной модели. Через него получают профессиональный контекст, причины решений, зависимости, сигналы и операции изменения.

Привет, Хабр. Я Игорь Юрченко, backend-разработчик Сбера. В предыдущей статье я описал автоматизацию развёртывания потоков NiFi, а сейчас расскажу о дальнейшем развитии этого подхода для интеграции с корпоративной системой управления секретами — SecMan. Буду использовать терминологию предыдущей статьи.

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

Я автоматизировал почти всю цепочку действий по фандрейзингу: сбор инвесторов из источников, отбор, отправку им сообщений через свою CRM, отслеживание ответов и вывод на звонок.

Чуть ниже описываю, как делал и какие цифры получились. Ну и где не получилось так, как мне бы хотелось.


Из чего складывается воронка

У меня пять ступеней, и на каждой стоит свой счётчик:
1.источники инвесторов
2.единая база + граф связей
3.скоринг и шорт-лист
4.отправка через CRM (лимиты, пауза, проверка доставки)
5.ответ → ссылка на звонок → звонок

На каждую ступень я ставлю счетчики. Просто иначе я не знаю, где теряю людей.

Откуда брать инвесторов

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

Второй источник это архив раундов: кто в какой проект заходил и с кем вместе. Фонды в архиве записаны текстом, поэтому я склеивал их с базой по нормализованному названию. По состоянию на сентябрь 2026 у меня получилось 49 056 совпадений с уже известными фондами и 1 761 новый фонд.

Третий источник это мои переписки в Telegram. По ним видно, с кем из мира фондов я уже знаком.

Это шестая статья цикла о том, почему акустика, которая хорошо измеряется, может плохо звучать.

В первой статье выяснилось то, что АЧХ суммирует всю поступившую энергию независимо от времени её прихода. Во второй — что помещение добавляет к звуку большое количество отраженных копий и резонансов, с которыми надо научиться дружить. В третьей — что качество воспроизведения низких частот сухие цифры характеристик не отражают. Четвёртая спустилась глубже — до самого динамика: идеального решения не существует, а ошибки проектирования после покупки уже не исправить. Пятая (ч.1 и ч.2) была посвящена искажениям: что это такое, почему порядок гармоники важнее её абсолютной величины, и почему слух отзывается на эти явления совсем не так, как измерительный прибор. На тот момент все закончилось заменой усилителя, но проблема с высокими частотами осталась на месте.

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

Главный вопрос звучит просто: все ли усилители звучат одинаково? Когда происходили описываемые события готового ответа у меня не было. Понимание приходило постепенно, шаг за шагом. Мешало то, что распутывались сразу две нити, усилитель и источник сигнала, и понадобилось несколько заходов, чтобы понять, кто из них за что отвечает. Поэтому объяснение первопричин моего недовольства и разделилось надвое: источникам будет посвящена отдельная статья.

Два фронтенда, один C#-мозг — что действительно различается, что похоже сильнее, чем принято считать, и что говорит рынок труда.

До 2019 года моим фронтендом были семантический HTML и CSS. Div'ы, классы, разметка, которую я мог удержать в голове. Я был бэкенд-разработчиком, и меня это вполне устраивало.

Потом случились две вещи. Компания попросила меня залезть в проект на Vue, а Microsoft выпустила Blazor. В следующие годы я плотно поработал с обоими: с Vue — у двух работодателей, с Blazor — на личном проекте, который до сих пор работает.

Это не статья с бенчмарками. Это про то, как эти две технологии ощущаются, когда мышление у тебя C#-овое.

Гайдлайны Apple, Android и Flutter по-разному, но одинаково настойчиво подталкивают задавать переход прямо в коде экрана — в документации go_router это штатный пример. В результате экран отвечает и за интерфейс, и за навигацию: его трудно переиспользовать, он знает про следующие экраны, а модульный тест превращается в интеграционный.

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

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

Нет, разумеется, хотят. И многие даже соглашаются. Правда потом возвращаются обратно в разработку, но соглашаются же. Так что вопрос стоит ставить ребром: «почему то, что им предлагают, вообще называется повышением».

У Максима было восемь лет опыта. В пятницу он сеньор. В понедельник он — кто? По грейду выше, но по факту джун в специальности, где у него ноль лет практики, с зарплатой и ожиданиями как от человека с восемью. И самое издевательское — ему никто не сказал, что он джун. Ему сказали «ты вырос». А что, если это не повышение, а смена профессии с билетом в один конец?

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

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

Как три вопроса к заказчику про жизнь после MVP поменяли ролевую модель портала: от одной таблицы связей к RBAC + ABAC. Внутри ER-диаграмма, SQL проверки доступа и пример на живом пользователе.

Плюс список вопросов, которые теперь задаём на каждом брифинге про доступы.

Мы выпустили очередной релиз NEOMSA ESB. Фокус этого цикла — состав поставки: мы прошли по всем контурам сборки, сформировали SBOM, устранили уязвимости уровня Critical и High и зафиксировали версии так, чтобы они не «уехали» при следующей сборке.

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

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

Это седьмая статья цикла “Код как борьба: Кратчайшая история IT”. И сразу хочу предупредить о структуре статьи, она будет чуть сложнее, чем обычно. Нам придётся держать в голове одновременно две вещи, которые нельзя смешивать в одну оценку. Техническое и юридическое наследие нашего героя - это одна история, вполне нейтральная. А личная куда более сложная.

Я помогаю жене войти в backend-разработку. На её примере хорошо видно противоречие, которое появилось у начинающих программистов: AI позволяет учиться быстрее, но одного работающего кода теперь недостаточно, чтобы доказать свою квалификацию.

До backend она пробовала войти в профессию через дизайн, затем изучала frontend. Первую работу во frontend получить удалось, но закрепиться в компании не получилось. Процессы были плохо выстроены, а общение с частью коллег оказалось токсичным.

Позже я предложил попробовать C# и backend. Это мой основной стек, поэтому здесь я могу не только посоветовать материал, но и проверить решение, объяснить контекст из реальной разработки или заметить, когда нейронка ведёт не туда.

Мы поправили резюме, подготовили рассказ об опыте и сделали тестовый task tracker. В нём есть задачи и подзадачи, которые можно завершать. Проект разворачивали в Azure примерно на месяц, чтобы пройти весь путь до работающего сервиса, а затем выключили. Я помогал с частью реализации и деплоем. С метриками жена разбиралась в основном сама.

Сейчас её приглашают на интервью. Основное препятствие переместилось в техническую часть: алгоритмическая практика, структуры данных, проектирование и способность объяснить написанный код.

Что именно AI упрощает в обучении

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

Меня зовут Саша Черток, руковожу отделом безопасности контейнерных и облачных технологий в Альфа-Банке. Расскажу, как вывести организацию в облако, даже если она максимально зарегулирована.

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

История разработки Ptah: как небольшой Go-first инструмент для миграций собственной базы данных постепенно превратился в полноценную open-source систему управления схемой БД. Причины появления проекта, какие архитектурные решения пережили весь проект, зачем понадобилась совместимость с Atlas, к чему привёл конфликт с его разработчиками, как это повлияло на развитие Ptah и что в итоге представляет собой решение сегодня.

Маршрут в .route.xml на том же движке, что и C#: подсказки в VS Code, проверка пакета в dotnet build, граф-редактор и горячая замена модуля.

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

В 4.0 у redb.Route появилась вторая запись маршрута: XML. Файл .route.xml кладётся в пакет, пакет в папку работающего сервиса, и меньше чем через полсекунды по новому маршруту идёт первое сообщение. При этом ...

Привет! Меня зовут Олег Игнатов. Сейчас я руковожу продуктовой аналитикой в Garage Eight. До этого я строил продуктовую аналитику в Литрес. Параллельно преподаю продуктовую аналитику в ВШЭ, менторю аналитиков и руководителей и веду свой канал.

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

В этой статье я разберу практические инструменты, которые помогли мне перейти от ручного управления к более автономной команде: регулярные 1–1, ревизию бэклога, командные ритуалы, приоритизацию, Focus Factor и развитие аналитиков через реальные задачи. Я не буду пытаться описывать идеальный процесс из учебника. Это скорее набор подходов, которые я проверял на практике и которые помогли мне уйти от хаоса.

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

Ученые из Университета Пенсильвании проанализировали с помощью LLM заголовки и аннотации 194,6 тысяч статей по социальным наукам за 1980–2024 годы. Они отобрали работы с кросс-секционными данными: в таких исследованиях ученые сравнивают людей, организации или другие объекты в один момент времени, а не наблюдают за их изменениями.

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

Тем не менее в 46,3% отобранных статей авторы использовали формулировки, которые прямо или косвенно указывали на причинность. Речь именно о заголовках и аннотациях к статьям. С 2000 по 2024 год доля таких публикаций выросла примерно с 20% до более 60%. В 2024 году в работах по бизнесу она достигла 84%, по экономике — 67%.

Кристофер Дафф, 40 лет, Сидней. Обвиняется во взломе судебной системы штата Новый Южный Уэльс.

Версия следствия — умышленно использовал ChatGPT для написания программы, предназначенной для загрузки большого количества документов и несанкционированного доступа к конфиденциальной информации. Полиция говорит, что дело касается почти 9000 судебных документов, и доступ Дафф к ним получил ещё в 2025. Тогда же ему предъявлили первые обвинения и провели обыск в его доме, изъяв два ноутбука, и отпустили под залог. Сейчас завертелось снова.

Вину не признает. В качестве доказательства суд хочет использовать переписку Кристофера с чатботом.

Первый такой случай в австралийском правосудии. Под катом — подробности и доводы сторон.

Дисклеймер. Данная статья не претендует на туториал, руководство к действию или повторение. В ней я пытаюсь ответить на давно дискутируемый вопрос: может ли вайбкодинг использоваться для нужд реального бизнеса? И кажется, ответ положительный — по крайней мере, в рамках осени 2026 года. Статья написана с согласия моего уже бывшего коллеги @smolyakov. В ней намеренно не указаны названия или торговые марки компании.

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

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

Недавно в BotFather у меня появилось сообщение о раннем доступе к Telegram Serverless. Telegram предлагает запускать код ботов прямо на своей инфраструктуре — без отдельного VPS, Docker, nginx и даже внешней базы данных.

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

Сразу оговорюсь: пока это early access. Есть ограничения, а привычный Python + aiogram туда просто так не перенести. Но сама идея получилась довольно интересной.

Допустим, завтра компания объявляет, что создала AGI и решила проблему alignment: система понимает намерения разработчиков, соблюдает ограничения и действует именно так, как от неё ожидают.

А теперь компания предлагает разрешить этой системе самостоятельно применять силу.

Вы готовы дать ей дробовик?

Три вопроса позволяют проверить переход от «система работает как задумано» к «ей можно доверить реальную власть над другими людьми».

Мощная видеокарта не всегда означает быстрый локальный запуск LLM. Разбираемся, почему GPU может простаивать, как на производительность влияют память, KV‑кэш и движок инференса, и что учитывать перед сборкой собственного стенда.

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

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

Привет, Хабр! Я Руслан Боярский, SRE в Т-Банке, отвечаю за надежность платформы Sage и принимаю активное участие в ее развитии. Sage — это платформа наблюдаемости, где мы собираем телеметрию. И я регулярно убеждаюсь, что в ИТ мы не можем существовать без метрик.

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

А еще опишу проблемы, с которыми можно столкнуться, и расскажу, как мы их решали. Попутно будет пара историй про инциденты. Поехали.

SQL‑инъекция через декомпиляцию: от JAR‑файла до захвата пароля

Материал носит образовательный характер. Все работы велись легально, в рамках пентеста, с письменного согласия владельца системы и в изолированном контуре. Название клиента и продукта не раскрываем — NDA. Имена классов, пакетов и таблиц в листингах изменены. Применяйте это только на системах, доступ к которым у вас есть. Доступ к чужим системам без разрешения преследуется по закону.

Корпоративная Java‑система: складской учет, веб‑интерфейс, HTTPS. Внутри — SQL‑инъекция без аутентификации в одном GET‑запросе, из‑за строки «... WHERE ID=» + параметр.

Разберем, как найти такую в приложении без исходников: декомпиляция JAR → чтение сервлетов → уязвимая строка → подтверждение через pg_sleep. Каждый шаг воспроизводим.

Что такое Obsidian и markdown?

Obsidian — это не облачный сервис, а просто очень красивый и удобный интерфейс для работы с локальными текстовыми файлами формата .md

Основные плюсы: Все файлы хранятся у вас. Они не пропадут, и вас не смогут забанить. Но главное — никакой сети для написания заметок вам не нужно. Они лёгкие по весу, так как любые фишки работают при помощи текстовых символов. В отличие от Word, например, мы передаём ненужные данные о размерах шрифта, самом шрифте, расположении каждого абзаца на странице и пр. Очень легко налаживать контроль версий, особенно с таким средством, как GitHub — легко отследить, какая строка изменилась, какой файл был перемещён и т.п. Есть множество уникальных фишек: возможность ссылаться на другие заметки, бесчисленное множество плагинов, самые разнообразные темы и многое другое.

В этой статье я подробно и просто расскажу, как освоить Markdown и Obsidian. Если вы уже используете это приложение, то вам будет полезно узнать о некоторых фишках, о которых вы можете прочитать в статье)

Подведены итоги ежегодного студенческого конкурса «САПР‑Перспектива — 2026». Экспертная комиссия рассмотрела 80 проектов из 20 образовательных организаций в 20 городах России и определила 14 лучших работ, отметив качество их исполнения и проработанность инженерных решений.

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

Командный трек

В командном треке победили Виктория Селиванова, Анастасия Гунько, Софья Базимирова и Арина Ягодина из Новосибирского государственного архитектурно‑строительного университета (Сибстрин). Под руководством Юлии Эдуардовны Чмир и Марии Сергеевны Тырышкиной они создали проект «Комплексная подготовка территории земельного участка, ограниченной ул. Амурской, ул. Расковой, ул. Титова и Широким переулком, г. Новосибирск».

Первые бытовые и любительские радиоприёмники появились задолго до повсеместной, «по городам и весям» осветительной сети, а приборы это были громоздкие, стационарные и главное дело — чрезвычайно энергорасточительные. Для питания одного несчастного усилительного каскада требовалось около 4 ватт от двух разных источников (низковольтный сильноточный накал и высоковольтный слаботочный анодный). Заметим, это 1920-е, 1930-е годы, львиной доле отечественных любителей радио, из готовых деталей были доступны, хорошо, если радиолампы, да кое-какие элементарные электротехнические материалы вроде изолированного провода. В продолжение нашей экскурсии по старинным самодельным резисторам [1], конденсаторам [2] и детекторам [3], посмотрим, как предки ухитрялись питать своё радио, восхитимся и ужаснёмся их возможностями, оснащением и энтузиазмом, полистаем ветхие радиожурналы. Речь о самодельных гальванических элементах и батареях нескольких популярных типов.

На даче у меня нет городского проводного провайдера. Есть LTE, MikroTik и локальная сеть. В городе при этом есть нормальная домашняя сеть, OpenWrt и цифровое ТВ от провайдера.

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

Продолжаем историческую одиссею в мир советского айти и микрокомпьютеров, служивших в него пропуском.

Всем привет! Нашел в блоге Kubernetes интересную статью о том, как написать собственный экспортер метрик на Go и подключить его к Prometheus. Автор разбирает весь путь: от выбора показателей и первых строк кода до развертывания в кластере и проверки сбора данных. Перевел материал и делюсь.

Как ошибка Google AI привела меня к собственному анализатору тренировок

Всё началось с выбора велокомпьютера.

Я сравнивал несколько недорогих вариантов и решил спросить совета у Google AI. В итоге он убедил меня выбрать CYCPLUS M1, рассказав среди прочего, что его можно подключить к компьютеру по USB как Mass Storage. Позже выяснилось, что USB там нужен только для питания, а FIT-файлы приходится получать по Bluetooth.

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

Так появился FIT Visualizer — расширение для VS Code с историей тренировок, автоматической сегментацией поездок и AI, который помнит предыдущие заезды и умеет объяснить, что изменилось.

При этом CYCPLUS M1 оказался только отправной точкой. FIT Visualizer работает с FIT-файлами от разных источников — Garmin, Wahoo, Polar, Suunto, COROS, Bryton, Hammerhead, Sigma и других велокомпьютеров, спортивных часов и тренировочных сервисов.

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

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