Все потоки

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

Google заблокировал Gemini для российских IP — и сделал это на нескольких уровнях одновременно: веб-интерфейс, мобильное приложение, прямой доступ к API через google.com. Обойти это можно тремя способами, у каждого свои компромиссы по стабильности, стоимости и сложности настройки.

Эта статья — разбор конкретных подходов к доступу: что работает в 2026 году, где ограничения, какой вариант выбрать под конкретную задачу.

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

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

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

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

На волне того бардака, что творится в найме, я как-то сидел и скролил вакансии go-разработчика на одной из площадок. И тут я подумал: “Я же всегда хотел в геймдев! Интересно, в геймдеве нужны гоферы?”. Я настроил фильтр и начал скролить по новой. Пока скролил, меня посетила отрезвляющая мысль: “Да не хотел я никогда в настоящий геймдев. Я хотел в тот геймдев, который я себе сам придумал”. Но не успел я эту мысль додумать, как наткнулся на вакансию гофера, как раз в геймдев. Пробежавшись взглядом по вакансии, я наткнулся на ключевой требуемый навык: необходим опыт в игровом матчмейкинге.

Что я знаю о матчмейкинге? Его Арпад Эло придумал, вроде?

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

Человеческая цивилизация держится в том числе на представлении об абсолютной неизменяемости прошлого. Но представьте себе существо, обладающее следующими свойствами:

1. Видит свою память как набор фактов в любой момент времни.

2. Обладает возможностью по своей воле удалять, добавлять, изменять любые факты своей памяти.

Большинство проблем с SSL-сертификатами возникает не при настройке TLS, а на этапе создания CSR: забытые SAN-домены, неправильные ожидания от wildcard, ручные ошибки в openssl.cnf. Разбираем, почему с сокращением срока действия сертификатов до 47 дней к 2029 году ручной выпуск перестаёт быть жизнеспособным, и какие инструменты приходят ему на замену.

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

Всем доброго дня! В предыдущей статье Кавай-Фокус 2.7: путь к MVP1 — цепочка таймеров и воспроизведение звука:

1. Добавлено воспроизведение звука таймера через Web Audio API;

2. Написана механика воспроизведения цепочки из таймеров для Pomodoro.

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

Все новые таймеры будут сохраняться в базу данных SQLite3, поэтому нужно будет написать CRUD-операцию для создания таймера. Также я добавлю операции для удаления и редактирования записей. К новому функционалу я подключу кнопки редактирования и удаления. Это позволит пользователю полноценно управлять таймерами.

Заваривайте чай, доставайте вкусняшки — пора «высаживать грядки из помидоров»! 🍅

Размышление о backend‑архитектуре между двумя крайностями: академической чистотой и радикальным прагматизмом. На примере read/write path, CQRS, кэширования готовых ответов и собственного framework‑а на Go я показываю, как архитектурные шаблоны сталкиваются с production‑реальностью.

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

Каждый бэкенд-разработчик, который хоть раз готовился к собеседованию, слышал про аббревиатуру ACID. Какая-то часть из слышавших сможет её расшифровать. Какая-то часть из расшифровавших — объяснить, почему важен каждый из принципов, скрытых за этими четырьмя буквами. И уж точно каждый из этих замечательных разработчиков знает цену букве «I» — isolation, изоляции транзакций.

Те, кого заинтересовал заголовок, скорее всего, относятся к одной из трех категорий читателей:

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

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

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

В этом материале систематизируем способы бороться с race conditions в Postgres и считаем, во сколько обходится каждый.

Как промт превратил языковую модель в проводника смыслов и источник инсайдов для бизнеса: AI-конструктор офферов

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

Как мы превратили персональную wiki в многопользовательский сервер знаний с графовым retrieval, доступом по ролям и MCP-протоколом

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

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

Каждый новый этап развития экономики порождал новые системы учёта.

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

Смотреть на это спокойно я не мог — и не из брезгливости. Я видел, сколько это стоит. Нарисовал флоу KYC один раз — иди рисуй его ещё семь, и каждый раз почти с нуля, потому что переиспользовать нечего. Вот где горело время.

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

OpenMediaVault, бот в Telegram и проблема с провайдером, которую пришлось решать через собственный десктоп.

Мультиконтекстный сайт на статических страницах без генерации на лету. Почему мы выбрали ручную вычитку и фиксированные версии

Мы не собирались писать эту статью. Мы всего лишь хотели воспроизвести результаты открытого бенчмарка ICASSP-2024 по низкодозовой компьютерной томографии, сравнить их с алгоритмами Smart Tomo Engine и понять свое место относительно опубликованных baseline и SOTA-решений.

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

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