Про перегрев рынка разработчиков не писал только ленивый, мне даже кажется, что среди фронтов проблема найма стоит острее, так как порог вхождения туда не так высок. Найти хорошую работу спецу во фронте, кажется стало сродни поймать золотую рыбку, хотя некоторым это удаётся.
Даже если отправить пол сотни откликов с резюме опытного фронта на hh, с небольшими зарплатными требованиями, не факт, что хоть в одной фирме тебя позовут на собес.
Более того, у этой проблемы есть и вторая сторона: совсем молодые выпускники курсов, самоучки, большинство из которых даже не окончили вуз или даже еще никуда не поступили, оценивающие себя как сеньора или минимум мидла, по причине огромной наглости или глупости, в силу везения или неграмотного рекрутера попадают на работу без должной оценки и выбивают себе высокие зп, порой не меньше чем у старых сотрудников, конечно как правило их увольняют, но к этому моменту они успевают попортить продукт и нервы тем сотрудникам, кто будет пытаться их учить.
Примерно так во многих местах работает найм
Кажется, что квалификация многих новых разрабов, особенно фронтов, сейчас очень низка, также как и тех кто ведёт их найм, и это не в единичных фирмах, я сталкивался с таким в половине мест где я работал.
Также сдаётся мне, что hh совершенно не подходит для поиска работы разработчиком.
В связи с этим хотел бы попросить совета у коллег по цеху, особенно фронтовиков, в форме трех следующих вопросов: 1. Где лучше искать работу, на каком ресурсе? 2. Замечаете ли вы, что hr часто набирают не тех кто реально способен, а тех кто умело врет или красиво улыбается? 3. Стоит ли искать работу фронту или стоит сменить профессию?
В этом докладе Илья Виссарионов рассказывает о практическом опыте компании «Диасофт» по импортозамещению крупной автоматизированной банковской системы, которая десятилетиями работала на Microsoft SQL Server.
Главной особенностью проекта стало то, что значительная часть бизнес-логики была реализована в виде хранимых процедур. Полное переписывание миллионов строк SQL-кода оказалось бы слишком дорогим и длительным, поэтому был выбран другой путь — развитие Digital Q.DataBase с максимальной совместимостью с Microsoft SQL Server и сохранением существующих приложений.
В докладе подробно рассматриваются реальные технические проблемы, с которыми столкнулась команда при переносе банковской системы на PostgreSQL-совместимую платформу: различия в типах данных, работе процедур, оптимизаторе запросов, производительности, временных таблицах, пользовательских типах данных и других механизмах СУБД.
Отдельное внимание уделено нагрузочному тестированию. Автор показывает, как поэтапная оптимизация Digital Q.DataBase позволила добиться производительности, сравнимой с Microsoft SQL Server, а по ряду операций — превзойти её, при этом сохранив существующую бизнес-логику без масштабного переписывания.
В этом видео вы узнаете:
🔹 почему импортозамещение крупных банковских систем требует особого подхода; 🔹 с какими проблемами столкнулась команда при переносе АБС с Microsoft SQL Server; 🔹 почему стандартного PostgreSQL оказалось недостаточно; 🔹 какие механизмы совместимости были реализованы в Digital Q.DataBase; 🔹 как удалось сохранить существующий T-SQL-код без его переписывания; 🔹 какие доработки были выполнены для повышения производительности; 🔹 как проводилось нагрузочное тестирование на реальных банковских сценариях; 🔹 каких результатов удалось добиться по сравнению с Microsoft SQL Server.
Если вас интересуют вопросы импортозамещения СУБД, миграции корпоративных систем или построения PostgreSQL-совместимых платформ корпоративного уровня — этот доклад будет полезен разработчикам, архитекторам, администраторам баз данных и техническим руководителям.
Digital Q.DataBase — российская СУБД корпоративного уровня, разработанная компанией «Диасофт» для замещения Microsoft SQL Server, Oracle и других зарубежных решений. Платформа позволяет сохранить существующие инвестиции в прикладной код и значительно сократить трудозатраты при миграции информационных систем.
Почти 10 лет в Авито — это не просто стаж. Это возможность наблюдать, как компания меняется изнутри, и самому влиять на эти изменения.
В этом выпуске «AviTalk» ведущий Виктор Раев, руководитель разработки юнита Services Base, поговорил с Александром Лукьянченко — техническим руководителем кластера Architecture. Саша прошёл путь от разработчика до менеджера высшего звена и видел Авито ещё в 2016-м — когда всё было устроено совсем иначе.
В разговоре — о том, как одному инженеру можно изменить работу целой компании, как зарождалась PaaS-платформа, что такое AvitoPlato и зачем оно нужно, и где брать мотивацию, когда занимаешься чем-то масштабным надолго.
Лайфхак для мозга:как закрывать задачи и не терять эффективность.
Вам знакомо чувство, когда 10 мелких незавершенных задач буквально живут в голове и забирают внимание, даже когда ты занята другим.
Это эффект Зейгарник или налог на внимание. Каждая незакрытая задача в списке тихо съедает часть рабочей памяти, весь день, фоном. Почему так происходит?
Мозг тянется к задачам с ощущением веса и масштаба, потому что там есть понятная награда — чувство, что сделал что-то значимое. Мелкая задача этого не обещает, и мозг её тихо игнорирует, раз за разом выбирая что-то покрупнее.
Единственное, что здесь работает — убрать у мозга возможность выбирать. Если задача занимает меньше двадцати минут, она уходит в работу первой, до всего остального. Так мелкие вещи перестают съедать фоновое внимание, которое нужно для по-настоящему сложных решений.
Я не музыкант, не композитор и не продюсер. Просто люблю музыку :)
С развитием генеративных моделей появилась бездна синтетических треков. На первый взгляд и слух многие из них неотличимы от человеческих, а местами даже лучше одноразовых коммерческих поделок. Но лично у меня от массового нейросетевого звука уже выработалось устойчивое слуховое утомление — слишком стерильно и предсказуемо.
Чтобы отсеять синтетический шум, появилось множество сервисов по распознаванию ИИ-музыки. Насколько я понимаю (возможно, в корне неверно), вся эта детекция основана на поиске в спектрограмме устойчивых паттернов: отпечатков периодических структур, артефактов нейросетевых вокодеров (типа EnCodec) и следов агрессивного сжатия.
Ради прикола я прогнал через довольно строгий детектор (aimusicdetector.online) несколько заведомо «живых» коммерческих треков. Ожидал увидеть чистый результат, но ИИ-артефакты детектировались везде — 15%, 18%, 20%. Ладно, списал на мастеринг.
Но вот попались две жемчужины, которые полностью сломали мне картину мира:
Strong codec evidence Confidence: High · Linear model probability: 86%Strong codec evidence detected in the residual spectrum. The fingerprint aligns with the current linear model for AI-music artifacts.
То есть детектор с высокой уверенностью называет живую стоковую музыку нейросетевой генерацией, ссылаясь на «совпадение с линейной моделью артефактов ИИ».
Уважаемое сообщество, хочу спросить:
Как это можно объяснить с точки зрения DSP и аудио-форензики? Это баг конкретной модели, или современные детекторы действительно путают артефакты brickwall-лимитеров / MP3-кодирования с нейросетевыми вокодерами?
Можно ли хоть в какой-то степени верить таким сервисам в 2026 году, или они уже сейчас дают слишком много ложноположительных срабатываний на профессионально сведённой музыке?
Есть ли среди читателей те, кто сталкивался с подобным в работе (A&R, саунд-дизайн, модерация контента)? Как вы верифицируете происхождение треков, когда автоматика врёт?
Буду благодарен за любые мысли, ссылки на исследования или личный опыт. Заранее спасибо! 🙏
Вычислительная сводимость и абсолютный детерминизм: Почему Стивен Вольфрам не прав
Если вы интересуетесь цифровой физикой, то наверняка сталкивались с проектом Wolfram Physics Project. Вольфрам постулирует: Вселенная это гигантский классический клеточный автомат, развивающийся по локальным правилам перезаписи. Из этого вытекает его знаменитый принцип вычислительной неприводимости (computational irreducibility). Он гласит: невозможно узнать состояние системы через N шагов, не просчитав пошагово все промежуточные такты. Коротких путей нет. Вселенная сама является наименьшим компьютером, способным смоделировать собственное будущее. Строго доказанная теорема автора о вычислительной сводимости (редуцируемости) наносит по этой концепции прямой математический удар, закрывая идеи Вольфрама для квантового мира.
Математика редукции: прыжок через миллиарды лет.Вольфрам строит модель на классических битах. В Quantumograph динамика перенесена в конечномерное гильбертово пространство. Эволюция графа задается глобальным оператором U, построенным на базе обратимых и консервативных квантовых затворов Фредкина (CSWAP) и Тоффоли (CCNOT).Поскольку эти вентили строго обратимы, представляющий их оператор фундаментально унитарен. Из этого математического факта выводятся два следствия:
Обход пошаговой симуляции: Чтобы узнать состояние Вселенной в далеком будущем, не нужно симулировать каждый такт планковского времени. Достаточно провести процедуру диагонализации оператора эволюции. После этого вычислительная стоимость предсказания на 10 шагов и на 1010 шагов вперед становится одинаковой. Мы можем мгновенно «прыгнуть» в любую точку временной шкалы, минуя последовательный пересчет промежуточных состояний графа. Вычислительная неприводимость здесь полностью ломается.
Принцип одного среза: Всего один пространственно-временной срез графа (условное «настоящее») полностью и точно детерминирует всю прошлую и будущую эволюцию. Будущее не вычисляется Вселенной по ходу дела. Оно вне времени зафиксировано в текущей спектральной структуре. В настоящем одновременно закодировано и прошлое и будущее и это строго математически доказывается в Quantumograph — теории.
Тут нюанс: теорема атакует не просто технический тезис, а саму онтологическую предпосылку Вольфрама. Вольфрам предполагает, что мир классически вычислителен и необратим на фундаментальном уровне. Quantumograph показывает: если фундаментальный уровень квантовый и унитарный (а не классический и необратимый), то необходимая предпосылка неприводимости отсутствует. Это не просто другой ответ на тот же вопрос -это другой вопрос.
Как это тестировать?
Главная претензия к подобным теориям (например, к теории струн) — это их принципиальная непроверяемость на современном этапе развития технологий. В основном они требуют построения коллайдера размером с галактику. Программа Quantumograph заявляется Автором как эмпирически тестируемая (отсюда и аббревиатура TQGT).
Автор TQGT предлагает наоборот проверять свою теорию в микромире и при температурах близких к абсолютному нулю, при этих условиях можно, так сказать «наблюдать шум ткани вселенной».
Quantumograph — это упор на реальную тестируемость уже сегодня так как проверки теории можно проводить на уже сегодняшнем технологическом уровне.
Проверка спектральной размерности на квантовых процессорах (QPU): Дискретная структура пространства предсказывает специфический профиль. Это должно быть различимо на современных квантовых процессорах при температурах 10-50 мК. Аномалии в профиле -прямая сигнатура дискретной геометрии.
Топологические аномалии решётки: Топологические солитоны (частицы) несут свой квантованный заряд. Отклонение от квантования (нецелое) является прямым признаком того, что конфигурация не термализована или решётка слишком груба. При правильной реализации на QPU целочисленность этого отклонения -прямое свидетельство TQGT.
Недавно я работал над встраиваемой системой, где на FPGA крутится EKF и немного управляющей логики. Кодировать такое на RTL — занятие в лучшем случае неблагодарное, поэтому я обратился к HLS (high-level synthesis) и стал смотреть, что предлагает индустрия.
У меня уже была довольно обширная обвязка для моделирования и верификации на питоне, поэтому в идеале хотелось чего-то, что принимает его напрямую, желательно с минимальной адаптацией: скормить инструменту нужные куски моих моделей и сразу получить рабочий RTL на выходе. Ещё хотелось плавающую точку. Добавлю, что у меня используется Lattice ECP5, а значит Vitis и вот это всё отпадает, так что я смотрел в сторону вендор-независимых инструментов.
Те, что умеют переваривать питон, есть, но на практике они, честно говоря, малопригодны — разве что для очень узкого набора задач. Я тестировал Polyphony, PyLog, Allo+XLS, Allo+Vitis (тоже мимо из-за Lattice) и Veriloggen. Они работают в том смысле, что переводят какой-то питон в какой-то RTL, но не в том смысле, что можно получить что-то практически пригодное, если нужно собрать, скажем, фильтр Калмана или хотя бы базовый ПИД-регулятор. Есть и мощные инструменты (XLS, Bambu и прочие), но они не поддерживают питон, плюс к ним есть ряд вопросов (особенно по части ECP5), о которых я как-нибудь расскажу отдельно.
Лично для меня это важная вещь, потому что она уже позволила сильно ускорить мою работу. Возможности сейчас в основном определяется моими насущными нуждами, но всё это расширяемо, и любой вклад приветствуются.
Подробное описание того, как оно устроено, есть по ссылке, но основная идея такая: парсим питон, строим граф потока управления, определяем, какие операторы нужны, конструируем минимальное специализированное VLIW-ядро, планируем микрокод (полностью статически, чтобы ядро оставалось простым) и генерируем Verilog вместе с дополнительными артефактами вроде Cocotb и отчётов. В комплекте есть примеры.
Я уже прогнал бенчмарки бок о бок с Bambu, XLS, Dynamatic и Vitis — результаты выглядят достойно; напишу об этом отдельно, если будет интерес (пока ещё в работе).
Что почитать по инфраструктуре: Docker, K8s, сети и защита серверов
Собрали свежие статьи из нашего блога — те, что легко затерялись в ленте, но которые стоит дочитать до конца. Если на неделе было не до Хабра, вот короткий дайджест с самым полезным.
Ваш docker-compose.yml сломается: 5 настроек, которые все забывают Локально всё крутится, на сервере неделю тоже — а потом Postgres съедает всю память, OOM-киллер убивает соседний сервис, а логи забивают диск. Всё лечится парой строк в compose-файле, но про них забывают: на машине разработчика они просто не проявляются. Разбираем пять настроек, без которых compose не доживёт до второй недели на проде.
Прощай, Fail2Ban: усиливаем защиту Netbird и Caddy с CrowdSec Fail2Ban десять лет был золотым стандартом, но он реактивен: чтобы он сработал, атакующему сначала нужно постучаться в ваш SSH пять раз. А что, если блокировать вредоносные IP ещё до того, как их трафик дойдёт до сервера? История о переходе на CrowdSec с пошаговыми примерами кода — и о том, как «шум» от атак упал на 99%.
Разбираемся с форвардингом IP-пакетов в сетевых уровнях L2 и L3 Чем коммутатор отличается от маршрутизатора, зачем нужен TTL, как устроена CAM-таблица и почему без ARP ваш пакет никогда не доедет до получателя. Спокойный разбор основ, который наводит порядок в голове — для тех, кто хочет наконец перестать путать L2 и L3.
Self-service деплой: как перестать ждать DevOps и ускорить команду Знакомая картина: разработчик полчаса висит в Slack, ожидая, пока кто-то накатит сборку на стенд. С ростом команды DevOps-инженер становится единственным шлюзом между кодом и продакшеном — и это горлышко съедает до 30% времени. Tech Lead рассказывает, как self-service платформа убирает узкое место, с кейсами Monzo и Spotify.
Kubernetes: архитектура и абстракции — полный гайд K8s называют стандартом, но понимание его механик встречается редко. Control Plane и Worker Nodes, Pod, Service, Deployment, Namespace — «прожиточный минимум» абстракций, без которых нельзя выходить в прод. Плюс отрезвляющая история о том, как Tinder год переезжал на кластер из 1000 узлов и что у них при этом ломалось.
От capabilities к AppArmor: что реально остановит атакующего в контейнере Уязвимость в веб-приложении, злоумышленник уже выполняет команды внутри контейнера — что именно его остановит? На одной и той же рабочей нагрузке показано, как последовательно срабатывают три слоя защиты: capabilities, seccomp и AppArmor. Где каждый помогает, где бессилен и почему работать они должны только вместе.
Хотите системно закрыть пробелы по инфраструктуре? Собрали большой дайджест по Linux, Docker, Kubernetes, CI/CD и сетевой безопасности: бесплатные уроки, практические гайды и курсы — всё в одном месте.
Реальность — это конечная сеть графа и почему С. Вольфрам не прав. Дискуссии о дискретности пространства-времени обычно крутятся вокруг петлевой квантовой гравитации или цифровой физики Стивена Вольфрама. Однако в тени этих гигантов развивается программа Quantumograph (Testable Quantum Graph Theory of Spacetime, TQGT). В последних препринтах (включая дополнения к v14) автор предлагает радикальную, жестко детерминированную модель, которая не просто заменяет гладкий континуум дискретной решеткой, но и математически закрывает вопросы онтологического хаоса, информационного парадокса и вычислительной неприводимости.
Давайте разберем, как устроен этот квантовый автомат, почему в нем нет места Большому взрыву, началу мира и почему Стивен Вольфрам, с точки зрения этой теории, оказался неправ.
Петлевая квантовая гравитация (ПКГ), теория струн и большинство современных программ квантовой гравитации работают сверху вниз: берётся известная физика (общая теория относительности, Стандартная модель) и квантуется, дробится, переформулируется. Исходная точка -непрерывный континуум, который затем дискретизируется как приближение или регуляризация.
Quantumograph изначально и оригинально работает наоборот «снизу вверх»:
Исходная точка -конечный граф на решётке Z4. Никакого континуума нет и никогда не было и он не квантуется, он возникает как эффективное описание на больших масштабах.
Метрика, поля, геометрия Эйнштейна это всё эмерджентные явления, выводимые из спектральных свойств лапласиана графа. Они не постулируются, а доказываются как предельные случаи.
Квантовая механика не надстраивается над классической физикой — она встроена в архитектуру с самого начала: степени свободы узлов суть кубиты. Эволюция это унитарный оператор.
Это означает, что Quantumograph не является очередной попыткой квантовать гравитацию. Это попытка показать, что и гравитация, и квантовая механика, и пространство-время это разные грани одного и того же объекта: конечного квантового графа.
2. Онтология графа: Забудьте про Большой взрыв
В классической общей теории относительности (ОТО) Вселенная начинается из сингулярности — абстрактной точки с бесконечной плотностью, где ломаются все законы физики. Quantumograph решает эту проблему радикально: никаких непрерывных пространств и бесконечностей не существует в принципе.
Фундаментом мира провозглашается конечный квантовый граф на решётке Z4 с кубитными степенями свободы. Т. е. четырёхмерный гиперкубический тор с периодическими граничными условиями. Узлы (кубиты) суть элементарные кванты пространства-времени, рёбра это связи квантовой запутанности. Все привычные нам континуальные понятия — метрика, физические поля, геометрия Эйнштейна — являются строго эмерджентными, то есть возникают лишь как приближение на макроскопических масштабах.
Эмерджентность здесь не метафора, а теорема: автор доказывает через Γ-конвергенцию (метод функционального анализа), что дискретное действие на графе в непрерывном пределе точно переходит в действие Янга-Миллса, а затем в действие Эйнштейна-Гильберта. Континуальная физика получается как предельный случай, а не постулируется.
Отсюда следует принципиально иной взгляд на космогенез:
Время как спектр: В теории действует жесткий постулат: время и спектр это эквивалентные понятия, описываемые на разных языках. Нет внешней «временной шкалы», на которой можно отметить точку «ноль» и спросить, что было до нее.
Большой взрыв без взрыва: То, что мы макроскопически воспринимаем как Большой взрыв — это не появление материи из ничего в пустом пространстве. Это специфическая фаза системы: область графа с экстремально высокой плотностью топологических связей. С точки зрения наблюдателя внутри системы эволюция разворачивается из сингулярности, но на онтологическом уровне это просто структурный пик в глобальном спектре графа.
ИИ для Университета 4.0, а «Королев ИИ» для МГТУ им. Н.Э. Баумана
Ключевой вызов для любого вуза, стремящегося к лидерству, — это не просто автоматизировать отдельные процессы, а создать единую «нервную систему», которая пронизывает все сферы деятельности: от образования и науки до управления и работы с талантами. Именно такую задачу мы ставим перед собой в МГТУ им. Н.Э. Баумана, разрабатывая научно-образовательную платформу «Королев ИИ».
Эта платформа — не просто набор модных чат-ботов. Это многоуровневая архитектурная среда, которая агрегирует и семантически обогащает данные, развёртывает специализированные сервисы на основе больших языковых моделей (LLM) и предоставляет единые интерфейсы для студентов, преподавателей, учёных и сотрудников. По сути, мы создаём «интеллектуальное ядро» цифровой экосистемы Университета 4.0.
«Королев ИИ»: архитектура будущего
В основе платформы лежит трехуровневая архитектура, которая обеспечивает её масштабируемость и адаптивность.
1. Уровень сбора и агрегации данных. Здесь формируется цифровой профиль каждого участника образовательного процесса. Это не просто сухие данные об успеваемости, а глубокий семантический анализ: тексты работ, участие в проектах, интересы и даже стиль мышления. LLM анализируют этот массив, выявляя латентные характеристики и создавая многомерный портрет человека.
2. Уровень интеллектуальных сервисов. Это «фабрика моделей» и «озеро научных знаний». Здесь развёртываются специализированные LLM-сервисы: от генерации персонализированных образовательных траекторий и адаптивного контента до интеллектуальной поддержки научных исследований и автоматизации управленческих процессов. Мы протестировали более 30 больших языковых моделей и создали первый рабочий прототип ИИ-ассистента, который понимает голос, обрабатывает запрос и даёт ответ естественным голосом.
3. Уровень взаимодействия. Это единая точка входа для всех пользователей. Студент получает персонализированного наставника, преподаватель — ассистента для автоматизации рутины, а учёный — инструмент для ускорения исследований.
Платформа «Королев ИИ» — это инструмент для достижения стратегических целей Программы развития МГТУ до 2030 года. Вот лишь несколько примеров того, как LLM меняют привычные процессы:
Образование. Мы решаем фундаментальную проблему «масштабируемой персонализации». ИИ-ассистент работает 24/7, помогая каждому из тысяч студентов осваивать материал в комфортном темпе. Платформа «Путь инженера» позволяет выявлять талантливых школьников и сопровождать их на всём пути: «школа — университет — индустрия».
Наука и инновации.LLM становятся катализатором продуктивности учёного. Сервисы семантического поиска, генерации гипотез и кода, поддержки публикационной активности помогают увеличить объём НИОКР и повысить количество публикаций в ведущих журналах. Мы создаём «озеро научных знаний», которое позволяет капитализировать интеллектуальный потенциал научных школ.
Управление и кадры. Интеллектуальная автоматизация документооборота, прогнозная аналитика и ИИ-агенты для консультирования сотрудников помогают сократить долю административного персонала при одновременном повышении качества сервисов.
Доверенный и этичный ИИ
Мы понимаем, что внедрение ИИ несёт не только возможности, но и риски. Поэтому этика — не внешнее ограничение, а внутренний принцип проектирования. В архитектуру каждого сервиса мы встраиваем механизмы объяснимости, аудита и защиты персональных данных.
Что дальше?
Мы уже прошли путь от идеи до действующего прототипа. Впереди — масштабирование, интеграция с отечественными программно-аппаратными комплексами и тиражирование нашего опыта. «Королев ИИ» — это не просто проект. Это прообраз новой операционной модели технического университета эпохи экономики данных, где технологии работают на человека, расширяя его творческие и когнитивные возможности.
Как мы воспроизводим функциональность Oracle и создаем аналоги DBMS-пакетов.
В предыдущем посте я рассказывал о технологии «Полиглот» в Digital Q.DataBase — возможности исполнять T-SQL "на лету" наряду с родным PL/pgSQL, что позволяет мигрировать приложения с Microsoft SQL Server.
Но полиглотность Digital Q.DataBase этим не ограничивается.
Сегодня хочу поделиться выступлением моего коллеги Ильи Лебедева, посвящённым Oracle-направлению. В докладе он подробно рассказывает о поддержке PL/SQL и о том, как Digital Q.DataBase помогает переносить системы с Oracle, сохраняя серверную бизнес-логику и клиентские приложения без дорогостоящей переработки.
В этом выступлении обсуждаются:
🔹 Как Digital Q.DataBase реализует полноценную поддержку Oracle-диалекта, включая пакеты, DBMS-пакеты и PL/SQL-код. 🔹 Почему SQL- и PL/SQL-код может выполняться без изменений. 🔹 Как работает мастер переноса баз данных и какие скорости миграции можно получить на практике. 🔹 Каким образом обеспечивается бесшовное подключение существующих приложений через OCI и JDBC. 🔹 Почему переход с Oracle на Digital Q.DataBase может занять месяцы вместо лет. 🔹 Как накопленный опыт миграций позволяет ускорять последующие проекты и снижать объем доработок.
В докладе также показаны реальные сценарии переноса корпоративных систем, демонстрация работы клиентских приложений после замены СУБД и подход компании к развитию совместимости с Oracle на основе запросов заказчиков.
Digital Q.DataBase — российская СУБД корпоративного уровня, разработанная компанией «Диасофт» для замещения Microsoft SQL Server, Oracle и других зарубежных решений. Платформа позволяет сохранить существующие инвестиции в прикладной код и значительно сократить трудозатраты при миграции информационных систем.
Представлен открытый проект ИИ‑студии для видеомонтажа OpenMontage — комбайн из ИИ‑агентов для полноценного выпуска видеороликов. Проект помогает превратить доступ к Claude Code, Cursor, Copilot, Windsurf или Codex в киностудию:
агенты берут на себя всё — от исследований и сценария до генерации видео, монтажа и озвучивания;
12 пайплайнов под любой тип контента — трейлеры, анимации, реклама, туториалы и так далее;
500 скиллов — генерация видео, аудио, музыки и картинок;
умеет работает с лучшими генераторами — Kling, Runway, FLUX, ElevenLabs и Suno.
24 июня 2026 года во время 46-го ежегодного собрания акционеров SoftBank Масаёси Сон молодился: чёрная водолазка, изящный чёрный костюм, аккуратно прибранные редкие седые волосы — и всё это на фоне большого тёмного зала и яркого экрана за спиной. Тем не менее Масаёси уже 68 лет. Он давно не походит на визионера из эпохи Alibaba или азартного инвестора времён Vision Fund.
Вообще-то Масаёси обещал уйти на покой в шестьдесят. Однако на этой встрече он со сцены заявил, что свой 50-летний план пересмотрел и собирается работать ещё лет 10–15. В планах у главы SoftBank — довести стоимость холдинговой компании до 1000 трлн иен (примерно $6–7 трлн). Фондовый рынок на подобные слова отреагировал с воодушевлением: в тот же день цена акций компании поднялась на 1,29 %, на следующий торговый день — подскочила ещё на 7,90 %.
Видеозапись мероприятия, конечно, доступна на сайте SoftBank, там даже есть перевод на английский. Интереснее разглядывать некоторые фрагменты из 66 слайдов презентации. В них Сон в очередной раз сравнивает SoftBank с несущей золотые яйца гусыней.
PDF со со слайдами тоже выложили. Среди явно сгенерированных с помощью ИИ картинок — откровения гуру бизнеса о том, что яйца не несут яйца, что акционерную стоимость создавала гусыня (где она очень довольна, поскольку её стоимость оценили в 71 золотое яйцо), а также иллюстрация фабрики золотых яиц внутри гусыни.
Презентации Масаёси Сона на самом деле всегда такие весёлые: там бывают перескакивающие яму коронавируса пегасы, которые позднее взлетают, странноватые равенства вида «25 − 4 = 9» с большим красным вопросительным знаком и круговые диаграммы, где разные доли отведены под смерть, одиночество и безысходность. Известную басню Эзопа Сон цитирует тоже далеко не впервые.
Привет. Я пишу бэкенд на Go, люблю строгую типизацию и предсказуемость. Но игнорировать тему ИИ-ассистентов глупо, поэтому я решил проверить, насколько они применимы для сборки нормального, защищенного проекта, а не просто кривых прототипов.
Чтобы эксперимент был чистым, взял стек, с которым не работаю каждый день: Node.js (Express 5) и Vanilla JS. На выходе получился хаб с утилитами: https://toolkitch.ru/
Главная идея проекта - простые инструменты средствами компьютера. Меня всегда раздражало, что популярные онлайн-сервисы гоняют данные на свои сервера, хотя по факту это может выполняться на компьютере. Здесь инструменты работают строго client-side, то есть в браузере пользователя. Ничего не устанавливал и не скачивал, но выполнил на компьютере.
По технической части:
Express 5 и Bootstrap 5.
Безопасность: настроил Helmet, прописал строгие CSP заголовки и CORS.
Писать код помогал ИИ-ассистент KodaCode. Впечатления положительные: нейронка полностью сняла с меня рутину вроде написания докер-файлов, конфигов Traefik и однотипной верстки под 7+ разных инструментов. Моя задача сводилась к контролю архитектуры и безопасности.
Сайт оптимизировал в том числе под ИИ-поисковики (GEO/AEO), чтобы тот же Яндекс Нейро или Perplexity могли индексировать страницы и предлагать эти утилиты пользователям по прямым запросам.
Посмотреть, что получилось, можно по ссылке выше. Будет интересно узнать, как вы используете ИИ в своей инженерной рутине, и какие специализированные плагины/инструменты можете порекомендовать. За критику по UI/UX сайта также буду благодарен.
Очень пятничное изобретение: оказывается, если отрезать у двух аквафоровских картриджей типа А5 верх и низ, то из-за рёбер жёсткости они вместе образуют офигенный корпус, легко продуваемый насквозь небольшим кулером (и даже есть к чему его внутри прикрутить, потому что есть промежуточная решётка). Единственный недостаток — вср экзотическая форма.
Рёбра тут не только рёбра, но и хитрая штука, позволяющая небольшим поворотом расклинить одну половинку в другой так, что держит ничуть не хуже резьбы.
…только кринжового жеста «большой палец вверх» в конце не хватает…
Вставляем так, чтобы рёбра были подальше друг от друга, потом поворачиваем так, чтобы стали поближе друг к другу — всё, корпус собран. Кажется, чипудипу пора мутить бизнес по переработке \s
Как я в Zabbix мониторю аккаунт в REG.RU: баланс, неоплаченные счета и сроки всех услуг - через API reg.ru
Домен можно сторожить по WHOIS: взял имя, посмотрел дату, повесил триггер «истекает через 30 дней». Но WHOIS видит ровно один домен и ничего вокруг. Он не знает, что на счёте кончились деньги, что висит неоплаченный счёт, из-за которого услугу снимут раньше срока, что в том же аккаунте ещё десяток доменов, SSL и хостинг. Поэтому я опрашиваю не WHOIS, а биллинговый API самого регистратора - он отдаёт весь аккаунт целиком. Собрал из этого шаблон под Zabbix 7.0, MIT. Расскажу, как он устроен и что в нём, на мой взгляд, сделано правильно.
Архитектура Три HTTP-айтема ходят в api.reg.ru - список услуг, неоплаченные счета и баланс - и складывают сырой JSON. Дальше всё считается из него: dependent items тянут баланс, сумму и число счетов через JSONPath, а LLD разворачивает прототипы под каждую услугу (ненужные типы отсекаются макросом-регуляркой). Каждая цепочка начинается с error_handler - битый или пустой ответ API не роняет айтем, а подставляет безопасное значение. На весь аккаунт получается несколько запросов в час, а не отдельная проверка на каждую услугу.
Что считаю правильным дизайном - две цепочки зависимостей Первое - nodata. Когда API регистратора отваливается целиком, каждый триггер «нет данных» (услуги, счета, баланс) хочет сработать сам, и ты получаешь пачку алертов про одну причину. Я завязал nodata услуг и счетов на корневой «No data from balance API». Полный отвал API теперь - один алерт, а не три. Корень я специально оставил без зависимостей, чтобы случайно не завязали и его, - об этом есть комментарий прямо в шаблоне.
Второе - сроки. На каждую услугу не один триггер, а каскад: ИСТЕКЛА (Disaster) → ≤7 дней (High) → ≤14 (Warning) → ≤30 (Info). Каждый уровень зависит от более тяжёлого. Поэтому услуга, которой осталось три дня, даёт один алерт High - а не три штуки (Info, Warning, High) одновременно. По мере приближения срока ты видишь ровно один триггер нужной серьёзности.
Для работы API, необходимо прописать разершенные IP в кабинете https://www.reg.ru/user/account/settings/api/, в настройках API задать адьтернативный пароль, и сохранить в макрос хоста {$RR_PASSWORD} как Secret. Логин - {$RR_USERNAME}. Для рег.облако взять API в https://cloud.reg.ru/panel/settings и сохранить в {$RRC_API_KEY}
Итог Баланс, неоплаченные счета и сроки всех услуг - под алертами в одном дашборде, без отдельного демона-прослойки. В репозитории два шаблона: разобранный выше под api.reg.ru (домены, хостинг, SSL) и отдельный под облачный api.cloudvps.reg.ru - там к балансу и срокам добавлен мониторинг самих VPS: реглеты, снапшоты, сети. Шаблоны, README и changelog - GitHub, PR и issues welcome.
А чем вы следите за биллингом у провайдеров и регистраторов - дёргаете API, или живёте на письмах «ваша услуга истекает»?
Создадим один и тот же REST-сервис на Spring Boot и на Quarkus, сравним время старта и затраты ресурсов.
Разберём настоящий случай из промышленной разработки. Вебинар будет полезен специалистам, которые хотят ускорить свои приложения и снизить счета за облако.
Содержание:
✅ Проблема долгого запуска и высокого потребления памяти в Spring Boot.
✅ Что такое Quarkus? Окружающая среда расширений, родная сборка.
✅ Живой код: создание REST-сервиса на Spring Boot и на Quarkus.
✅ Измерение времени запуска и потребления памяти.
✅ Как родная сборка ускоряет размещение в Kubernetes и снижает затраты.
✅ Настоящий случай из практики автора.
✅ Как продолжить изучение Quarkus.
🧑🎓 Спикер: Чвилёв Константин, эксперт в области разработки ПО
