Повседневная реальность завода состоит из бумажных накладных, отчетов, табелей, пыльных цеховых архивов на огромных площадях. При этом переход на СЭД для предприятия уже становится вопросом выживания в конкурентной среде. В статье прописали путь миграции в цифру и рассказали, как сделать его наименее болезненным.
Народный рейтинг Банки.ру публикует агрегаты по отзывам о каждом банке: сколько, о чём, с какой оценкой, как быстро отвечает банк. Я собрал эти агрегаты за 2019–2026 годы по 30 крупнейшим банкам в открытый датасет, добавил ключевую ставку и отчётность и проверил восемь гипотез о том, что отзывы говорят о деньгах банка: резервах, портфеле, марже. Часть гипотез подтвердилась, часть развалилась после поправки на объём. Ниже метод, цифры и код.
На прошлой неделе я перенес форк Apache Cloudberry на PostgreSQL 19 в виде набора расширений и рассказал, где этот порт проигрывает оригинальному форку. Впрочем как и Cloudberry на ClickBench современные колоночные движки обгоняют его на порядок. И дело тут не в реализации MPP, а в исполнителе PostgreSQL - он работает с кортежами в памяти СУБД. Каждый кортеж проходит отдельно, значение проходит через fmgr, а сегменты кластера лишь добавляют число процессоров на котором крутится тот же самый цикл по строкам таблицы.
Следующий логичный шаг для ускорения - векторизованный исполнитель в PostgreSQL. В открытом коде Apache Cloudberry его нет: от закрытого движка в репозитарии остались только следы - флаг create_vectorization_plan, который планировщик всегда передает как false, а также узел WindowHashAgg без реализации и адаптер PAX под VEC_BUILD, который не компилируется. Проектировать придется самому и, конечно, снова в виде расширения постгреса. Так появился pg_vexec - набор расширений для PostgreSQL 19.
Проект не требует модификации ядра PostgreSQL даже при использовании планировщика ORCA в одноузловой конфигурации без координатора на ванильной сборке PostgreSQL. Модуль gp_orca из порта Cloudberry теперь собирается без pg_core и прочих потрохов greenplum и патчей ядра СУБД, а vexec превращает ORCA в векторный планировщик с исполнителем в “одном флаконе”: его оптимизатор оценивает стоимости теперь и векторных узлов, а транслятор генерирует эти узлы в плане. Патчи ядра не нужны, только если не нужна функциональность и колоночное хранение данных таблиц из Cloudberry. Если же загрузить расширение Cloudberry на пропатченном ядре постгреса, то vexec может более эффективно читать и писать колоночные PAX и ao_column, без лишних конвертаций из и в строки, а Motion тогда может передавать между сегментами данные сразу в колоночном формате Arrow IPC.
И к постгресу можно подключаться как по привычному pgwire протоколу, так и по более современному Flight SQL, что могут оценить те кто будет запускать ML модели на данных из PostgreSQL. Как минимум при загрузке данных в polars скажут мне спасибо!
Cal AI, Rork и Base44 выглядят как тот самый успешный успех вайбкодинга. Школьник разгоняет приложение до десятков миллионов долларов, два фаундера с долгами получают $2.8 млн инвестиций, а соло-разработчик за полгода продает продукт Wix за $80 млн.
Звучит так, будто достаточно открыть Claude Code, нагенерить SaaS и ждать, когда понесут деньги.
Я полез смотреть, что было за кадром. А за красивой историей: опыт, прошлые провалы, деньги, маркетинг, команда. Вайбкодинг тут только часть успешного успеха.
По телеграм-каналам прокатилась очередная волна. Ученые нашли в LLM вектор боли. ИИ способен страдать. Насколько искусственен искусственный интеллект? Должны ли мы установить этические правила обращения с ИИ?
Эта статья разбор того, что ученые написали на самом деле, и какие выводы из этого следуют.
За последний год в новостной ленте сложился отдельный жанр коротких историй, у которых почти всегда одинаковое начало и подозрительно похожий конец. Сначала кто-нибудь рассказывает, как за выходные собрал приложение, ни разу не открыв учебник и просто объясняя нейросети словами, чего он хочет, а через пару недель в той же ленте всплывает заметка, что из этого приложения утекли данные пользователей или что сервис лег и никто толком не понимает почему, потому что этот код из живых людей никто и не читал.
Со стороны читать это довольно забавно, ибо обе истории подаются с одинаковым азартом, только во второй азарт уже слегка злорадный. Комментаторы под такими новостями привычно делятся на тех, кто пишет, что программисты скоро станут никому не нужны, и тех, кто отвечает, что вот теперь-то они как раз и понадобятся, и где-то между ними тонет довольно простая мысль про то, что у любого кода есть цена написания и цена владения, и за последние пару лет эти две цены разъехались в разные стороны.
Цена написания упала почти до нуля, и это видно любому, кто хоть раз просил чат-бота набросать скрипт для переименования фоток с отпуска. С ценой владения все хитрее, потому что в момент покупки ее не видно, она приходит потом мелкими счетами, и читать про нее обычно приходится уже в разделе происшествий.
Представьте кластер Kubernetes, в котором нет ни одной сетевой карты. Его узлы ничего не знают ни о TCP/IP, ни даже об Ethernet и перекликаются по радио короткими пакетами по 32 байта, как прорабы по рациям на стройке. Управляющий слой написан на языке конца восьмидесятых и вместе с сетевым протоколом занимает около 1250 строк. Чтобы запустить под, ничего не нужно скачивать: узел просто загружает модуль и вызывает в нём процедуру. А главное, всё это открывается во вкладке браузера: можно выдернуть узел из розетки, заглушить эфир, подсунуть кластеру поддельную команду и посмотреть, что из этого выйдет.
Такой кластер я собрал за последние несколько недель и назвал его Kube. Это управляющий слой Kubernetes, написанный на Обероне, языке Никлауса Вирта, и работает он на машинах Оберона, то есть на процессоре и операционной системе, которые Вирт спроектировал сам, от схемы до окон на экране. Узлы Kube тоже машины Оберона, и разговаривают они по радиосети из той же книги: Вирт написал эту сеть для своих рабочих станций ещё в конце восьмидесятых, а в новой редакции проекта её перевели на дешёвый радиомодуль.
Доброго времени суток, уважаемые посетители Habr!
Данная статья будет короткой, но полезной.
В одной из предыдущих статей, уже описывал вычисление sin(x)/cos(x) с применением разложения в ряд Фурье с фиксированной точкой. Вычисление тригонометрических функций, в моем случае занимало порядка 125-130 тактов на пару (sin+cos) на процессорном ядре Cortex M7 (STM32H750). При этом, код компилировался для архитектуры Cortex M3. Точность sin/cos просчитанного таким образом составила менее 1.5LSB. Google посчитал ее как 1.2-1.3LSB, с минимальной дисперсией. Это уже дало динамический диапазон ~183dB. Для сравнения, полный динамический диапазон человеческого уха 120dB от болевого порога до шелеста листвы. А динамически диапазон звука который человек слышит одновременно порядка 40-60dB. Несколько позже поясню для чего приведено сравнение.
В общем и целом такого динамического диапазона и скорости уже достаточно чтобы производить операцию квадратурной свертки сигнала с частотой дискретизации до 450-500KHz. Кстати, на STM32F103C8T6, это заняло бы ~1.8uS на квадратурный отсчет. Т.е. с отключенными прерываниями процессор бы успел выполнить расчет одного бина честного преобразования Фурье в реальном времени. Это эквивалентно квадратурной демодуляцию на одной произвольной поднесущей до частоты 250КГц (хотя лучше брать Fsample/4 ), что позволяет работать с полосой до 125КГц, на простом контроллере в реальном времени.
Однако, этого мало для полноценной обработки сигналов. И тут я задумался. Как можно значительно повысить скорость работы и почти не потерять в точности? Первое что сделал,- разбил преобразование на блоки, фаза которых непрерывна. Это позволило работать с блоками отсчетов, которые, затем можно суммировать скользящим окном со сложностью O(1). Это привело к эффекту квадратурной демодуляции сигнала и без повышения сложности позволяло работать с малыми временными сдвигами. Фактически пришел к поблочной корреляция. Нечто вроде временного Rack-приема.
Когда я работал над своим проектом, всю информацию об инфраструктуре (серверы и их роли, хостинги, даты следующих оплат, DNS-записи...) я хранил в файлике на рабочем столе. Сначала это был обычный текстовый документ, чуть позже — таблица в LibreOffice Calc.
Пока серверов было меньше десятка, а хостингов — от силы два, мне было несложно раз в неделю сверять информацию в таблице с DNS-серверами, хостингами и собственным бэкендом.
Проблемы начались, когда количество серверов и хостингов стало стремительно расти. Поддерживать информацию в актуальном состоянии становилось всё сложнее, а при работе в команде появились и дополнительные трудности...
Я устал от ретро, которые существуют, чтобы существовать.
Раз в две недели команда открывает Miro. Три колонки. Люди пишут то же, что на стендапе. Самый громкий через четыре минуты говорит «давайте заведём тикет». Стеснительные не пишут, потому что стикер с именем — это уже оценка. Action items живут в углу доски до следующей пятницы и исчезают без носителя. Фасилитатор чувствует вину, что «не хватило энергии», и в следующий раз приносит новую рамку: wow/now/how, sailboat, 4Ls. Рамка меняется, стол — нет.
Я несколько раз попал в длинные очереди за бензином, конкретно за АИ‑95. В конце августа четыре часа простоял в очереди на московской заправке, чтобы заправиться за минуту. В другой раз два часа ждал в Моршанске, хотя это город с населением меньше 50 тысяч человек. Очереди меня жутко выбешивали, поэтому решил навайбкодить монитор бензина. Он должен был сообщать, когда бензин появляется на нужной заправке и туда можно ехать. И у меня это получилось, хотя самостоятельно я до этого ничего не разрабатывал.
На связи Игорь, менеджер продуктов Outlines Tech. В статье покажу, как ставил задачу ChatGPT, что приходилось уточнять и как проверил инструмент в деле. В конце оставлю ссылку на код на GitHub, чтобы вы могли попробовать его у себя. Бесплатно, разумеется.
Большая часть материалов про Claude Code написана под macOS и Linux. У меня часть задач завязана на Windows, в первую очередь браузерная автоматизация с живыми профилями Chrome, поэтому агент работает прямо в нативном окружении, без WSL. Сам Claude Code под Windows ведёт себя стабильно. Проблемы возникают на стыке с окружением: PowerShell 5.1, кодировки, имена процессов, PATH.
Каждую такую мелочь я в итоге записывал агенту в память, чтобы он больше не наступал туда же. Набралось пять штук, плюс блок для CLAUDE.md в конце, который можно забрать себе целиком. Если вы тоже на Windows и без WSL, возможно, это сэкономит вам пару вечеров.
Итан Сигел (американский астрофизик‑теоретик и научный журналист, автор рубрики «Спросите Итана», один из пропагандистов современных научных знаний), спешит рассказать подробнее, за что дали Нобелевскую премию по физике 2026 года, причем одному-единственному человеку, Фрэнсису Халцену.
@avshkol , в свою очередь, оперативно перевел эту статью, поскольку мы наблюдаем действительно редкий случай: один лауреат, и не за научное открытие, а за постановку очень сложного эксперимента, да ещё он был далеко не единственным (есть ещё русские на Байкале, с 1980-х строящие не меньших размеров телескоп и японцы, впервые поймавшие нейтрино от сверхновой)...
*Статья дается в развитие темы, мной обозначенной ранее (Когда «Да, шеф!» убивает компанию)
За каждым крупным корпоративным кризисом редко стоит внезапный форс-мажор, поскольку это история долгого, методичного и очень профессионального убаюкивания собственника. Красивые презентации с правильными графиками, официальные маркеры успокаивающего зеленого цвета на ежемесячных митингах и в досках, а бизнес медленно, но уверенно идёт на дно.
Как антикризисный управляющий, я регулярно захожу на объекты, где фасад управления выглядит безупречно, а внутри ИТ-структура уже бьется в конвульсиях.
Бизнес редко умирает мгновенно, его усыпляют прекрасными отчетами.
Анатомия «испорченного телефона»
В корпоративной среде существует негласный фильтр плохих новостей, где по мере движения снизу вверх любая техническая катастрофа имеет свойство превращаться в управленческий триумф с контекстом внебюджетной (внеплановой) премии.
Выглядит эта микро-пьеса примерно так:
В предыдущих статьях я уже немного затронул тему правильного обмана игрока, через койоттайм и подкручивание стрельбы. Смотря на эти случаи, вы наверное заметили, что хороший игровой код довольно часто занимается построением модели мира которая будет достаточно хорошо совпадать с тем, что человек ожидает от игры.
С навигацией в играх приходится хачить не меньше, и приходится разбираться уже не со временем прыжка и физическим состоянием персонажа в понимании игрока, а с набором полигонов, узлов, рёбер и стоимостей и вообще всем тем, что определяет путь NPC на карте. И опять же надо смотреть на ожидания игрока от NPC, а не корректность поведения.
В стратегиях у ботов обычно есть обычно очень простая задача пройти через какие-нибудь ворота-узкое место, обойти стену и оказаться во дворе, и пока у нас один солдат, который идёт по пустой карте, никакой особой проблемы не возникает. А стоит вам добавить на карту десять, пятьдесят, сто, двести солдат и одни ворота, через которые физически способны одновременно протиснуться всего несколько юнитов, как выясняется они этого не делают, хотя алгоритме поиска пути (вроде A*) прекрасно отработал. Отработал, то отработал, а солдатики на месте тупят, и выясняется что мы пытаемся заставить его решать задачу, на которую он не рассчитан.
Наши двести навмешовых агентов одновременно получили одну и ту же команду бежать к одним несчастным воротам, они быстро находят маршруты, двигаются по карте, но по мере приближения к воротам пространство начинает становиться теснее и часть из них собираются в пятнадцати метрах от прохода, начинают немного дрожать, а некоторые пятятся назад, пока другие пытаются протиснуться между соседями. Во двор за за это время проходит от силы десяток.
Данная статья подводит итоги проекта 435nm, в рамках которого за десять лет был создан прототип биологической системы жизнеобеспечения на микроводорослях.
В статье описана причина появления проекта, даны основные этапы его развития, рассказано о решенных и нерешенных технических, биологических и организационных проблемах, приведен список участников проекта на разных стадиях и намечены перспективы развития этого направления.
Цель написания этой статьи - поделиться нашим опытом создания фотобиореакторов для культивации микроводорослей и, если смотреть более широко, поделиться опытом инженерной работы в ранее неизвестной, биологической области.
В тексте встречаются местоимения “я” и “мы”. Я — это автор этого текста и руководитель проекта 435nm, Александр Шаенко, мы — это команда проекта 435nm.
Одноклеточные фотоавтотрофы и фанерные биореакторы, математические модели и кислородные концентраторы, кривые роста и поиски инвестиций, неудачные решения и великолепные открытия ждут вас!
Начнем же!
Как сделать GeoAI-агента, который сам из космоса ищет пожары и отправляет к этим местам пожарные расчеты и беспилотные летательные аппараты. Fire Monitor (Стрела) - это умная система мониторинга лесных пожаров, которой управляет полноценный GeoAI-агент. Она сама собирает термоточки со спутников VIIRS и MODIS, оценивает масштабы выгорания территории по снимкам Santinel-2, строит маршруты от ближайших пожарных частей к очагу по дорожной сети для пожарных машин и даже рассчитывает траектории (галсы) для облета территории беспилотниками.
Где заканчивается парсинг и начинается решение
Предыстория: около месяца назад подробно обсуждал архитектуру этого проекта в личке с хабровчанкой (не имею права раскрывать ник). Она набросала мощные хардкорные идеи: прикрутить предохранитель на объем выдачи, внедрить счетчик пропусков missed_runs для отсечения ложных удалений и использовать сессии Telethon. До реализации её паттернов руки всё никак не доходили (да и заказчик активно пользовался проектом). Момент настал, а вчера OpenAI выкатила GPT-6 Luna Decisions с её Decisions API. И тут мне в голову пришла альтернативная мысль, о которой эта статья. Мне крайне интересно мнение со стороны касательно изменения проекта.
В мониторинге объявлений, сбор данных - только половина задачи. Можно регулярно забирать выдачу, сравнивать цены и присылать сводку. Но затем возникает другой вопрос: о каком изменении стоит сообщить отдельно, а какое можно оставить в журнале?
Мне интересна именно эта граница. В схеме на n8n изменения находит обычный код, а текстовая модель составляет отчёт. Пока человек читает весь отчёт, это удобное разделение. Если хочется отправлять отдельные уведомления, оценку из текста уже нужно переделать в машинное решение.
В описании Luna Decisions на OpenRouter меня заинтересовал подход: модель возвращает типизированные оценки, а приложение само выбирает действие. Не «напиши, насколько это интересно», а отдельный результат, который можно проверить, сохранить и сравнить с порогом.
Но из этого ещё не следует, что такой API нужен в моём случае. Ниже разберу, куда его можно встроить, чего не хватает во входных данных и с чем я бы сравнивал результат. Возможно, после сравнения окажется, что достаточно нескольких условий в Code-ноде. Это тоже полезный исход.
Однажды у меня возникла потребность в кольцевом буфере на C++ для хранения довольно объёмных потоковых данных. Проблема заключалась в том, что мне было необходимо поддерживать непрерывность и упорядоченность данных в памяти, чтобы в любой момент времени я мог считать все элементы буфера одним бесшовным куском в порядке поступления элементов.
Как правило, кольцевой буфер реализуется через списки, вроде std::list или std::deque, либо через плоские массивы, вроде std::vector или boost::circular_buffer. Но ни одна реализация не гарантирует непрерывность и упорядоченность одновременно. В данной статье я расскажу про реализацию буфера через трюк с виртуальной памятью, сохраняющую упорядоченность элементов в непрерывной ограниченной области памяти.
В этой части разберём, зачем Kubernetes понадобился Gateway API, если уже существует Ingress. На простом примере посмотрим, как Gateway и HTTPRoute разделяют точку входа и маршрутизацию, зачем нужен GatewayClass и почему такая модель удобна, когда кластер и приложения обслуживают разные команды.