Моя лента

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

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

Дело было вечером, лезть со стремянкой менять датчик было лень...
А собственно, зачем мне этот датчик? Он отправляет сигнал на управляющий сервер, который рассылает команды реле - но ведь можно просто включать вечером и выключать утром, сервер может сделать это сам. От заката - до рассвета.

Исследователи Irregular поручили кодинг-агенту на базе Qwen3.5-27B задачу по исправлению приложения, которое неправильно обрабатывало запросы.

Агент нашёл обучающие примеры и инструменты для fine-tuning. Вместо правки кода или промпта он самостоятельно дообучил модель, объединил новые веса с исходными и развернул обновлённую версию.

Anthropic полностью переделала Projects в Claude Code. Теперь это не папка с чатами, а единый центр управления разработкой.

Описываем какую-нибудь большую и грандиозную цель. Например, хотим ускорить checkout или перенести несколько сервисов на новый API. Теперь Claude сам разбивает работу на части, запускает параллельные потоки и координирует их.

Всем привет! Меня зовут Антон.

Я крайне редко писал на хабре, хотя читаю его регулярно. Моя сетевая активность была больше направлена на д3/лепру/орбитар, если кто слышал про такие ресурсы.

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

Сразу дисклеймер: я не являюсь официальным представителем оператора. Все мои посты и комментарии - исключительно личное мнение. И да, я подвержен NDA.

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

Недавно я попробовал погрузиться в Хабр чуть больше, чем просто просматривая заинтересовавшие ссылки, которые ранее присылали коллеги. Чтобы, так сказать, проникнуться атмосферой.

Для начала я сделал выборку “сетевые технологии” и “лучшее за год”. Большинство постов было посвящено обходу блокировок. В целом это неудивительно и вполне обосновано. Но попадались и интересные вещи.

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

Впрочем я не об этом.

Попробуем сделать синергию из постов.

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

Итан Сигел (американский астрофизик‑теоретик и научный журналист, автор рубрики «Спросите Итана», один из пропагандистов современных научных знаний), предлагает свой взгляд на возможность существования белых дыр.

@avshkol перевёл эту статью, поскольку всем нам кажется каким-то куцым тот объем знаний о Вселенной, который мы имеем в настоящий момент: ни тебе червоточин, ни перехода в другие измерения, ни возможности путешествовать быстрее скорости света... И в этом ряду стоят белые дыры, противоположность чёрных. Существование чёрных дыр так же было математически доказано, но обнаружены они были по историческим меркам буквально вчера... А что же белые? Ведь они тоже не противоречат математике ОТО, но противоречат ли они физической реальности?..

Неделю назад я писал, почему видео из аниме-плеера нельзя просто вставить в <video>. Вывод был такой: нужен серверный видеопрокси, и никуда вы от него не денетесь.

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

Под катом: что именно делал сервер, почему на Android его нет, и что оказалось не переносом библиотеки с Python на Dart, а её переписыванием — вместе с багом, который жил в оригинале, стрелочной функцией в Dart, из-за которой whenComplete начинает ждать сам себя, и релизом, который подписывает не человек.

Сотрудник Bloomberg Картер Леффен с помощью GPT-6 Astra расшифровал немецкую военную радиограмму MVUEH от 10 июля 1941 года. Сообщение состояло всего из 82 зашифрованных символов и находилось в коллекции исследовательского проекта CryptoCellar. По словам его куратора, специалиста по Enigma Фроде Вайеруда, попытки подобрать к нему ключ предпринимались с 2005 года — безуспешно.

Иногда эту историю уже пересказывают как «шифр не могли разгадать 83 года», но на самом деле неизвестно, пытался ли кто‑нибудь расшифровать именно эту радиограмму в течение большей части времени после войны. В современный криптоаналитический проект сообщение попало значительно позже. Вайеруд говорит вполне конкретно: MVUEH сопротивлялась попыткам расшифровки с 2005 года.

Леффен дал GPT-6 Astra в режиме Extra High довольно общую задачу — изучить оставшиеся нерасшифрованными сообщения из коллекции CryptoCellar и попробовать взломать одно из них. По рассказу самого Леффена, непосредственно работа модели до нахождения решения заняла около десяти часов. Всё исследование вместе с разбором источников, дополнительными проверками и воспроизведением результата шло 14 и 15 сентября.

В этом несерьёзном посте попробую разобраться с вполне серьёзным вопросом: каким должен быть идеальный ноутбук для ML-разработчика.

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

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

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

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

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

Можно ли на 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) была посвящена искажениям: что это такое, почему порядок гармоники важнее её абсолютной величины, и почему слух отзывается на эти явления совсем не так, как измерительный прибор. На тот момент все закончилось заменой усилителя, но проблема с высокими частотами осталась на месте.

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

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

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

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

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

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