Все потоки

Нашёл робопалец и теперь включаю рабочий компьютер удалённо

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

Иногда мне нужно подключаться к рабочему компьютеру удалённо. И всё бы хорошо, но дистанционный доступ бесполезен, если устройство выключено. Технология Wake-on-LAN (удалённое «пробуждение» по сети) тоже не спасает: после отключения электричества компьютер полностью обесточивается. 

Раньше решение этой задачи превращалось в отдельный квест: попросить кого-то зайти в офис, объяснить, где стоит системник, какую именно кнопку нажать, дождаться неуверенного «вроде нажал». Но я нашёл вариант проще.

Есть маленький умный толкатель кнопок: пластиковый кубик примерно 4×4 см, внутри один рычажок, который ездит вверх-вниз и физически нажимает на то, к чему его приклеили. Ставишь такой кубик у кнопки питания и дальше включаешь компьютер голосом. Команда – и рычажок жмёт за тебя. Только важно не забыть про шлюз – небольшой хаб, который связывает кубик с интернетом. Настраивается быстро и один раз.

Подключать Алису не обязательно – можно управлять напрямую через приложение SmartLife. Но, если хочется поговорить, можно и управление голосом через Алису добавить :)

Что нравится: ничего не надо перенастраивать, вскрывать или паять. Просто приклеил, настроил и пользуешься. И главное – это универсальное решение для кнопок, которые иначе никак не автоматизировать. Рычажку всё равно, на что давить: старый выключатель, техника без Wi-Fi или любая другая кнопка, до которой неудобно добираться.

Если вам тоже регулярно приходится включать/выключать какие-то устройства, – скорее всего, вы можете отдать эту задачу рычажку. Так что забирайте идею – работает)

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

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

Мой бэкэнд реализует ряд REST API функций и начинает свою работу с ловли входящих соединений на порту. Для этого я использовал net.Listener, который как выяснилось испытывает сложности с повторным захватом порта, а SO_REUSEADDR, который прекрасно работает в С++ в Go работает, как-то, не очень. Автоматический запуск приводил к порождению бесконечного числа процессов, которые только писали в лог ошибки безо всякой полезной деятельности. И когда мне надоело заставлять это работать я решил использовать старый и проверенный метод: сделать так, чтобы бэкэнд запускался по каждому порту один раз. Оставим в стороне неинтересные подробности того как связывать процессы с конечными точками (endpoints).

И всё было прекрасно до тех пор, пока я не добрался до того, что os.FindProcess() всегда находит процесс. Даже если процесс уже завершился. В случае запуска на POSIX системе можно было бы использовать process.Kill(0), но на моём Windows 11 это не работает. И, в условно переносимом коде появилась ветка для Windows:

var perr *os.SyscallError if runtime.GOOS == "windows" && errors.As(errKill, &perr) && errors.Is(perr.Err, syscall.ERROR_ACCESS_DENIED) {
log.Warnf("unable to kill dead process: %d. Error: %v", pid, perr)
} else {
log.Warnf("unable to kill process: %d. Error: %v", pid, errKill)
return errors.New("previous process running")
}

А морали в данном посте не будет. Для меня это сильно похоже на Python, где я также делил код на Windows и POSIX. Вполне вероятно, что я просто не знаю простого и лёгкого способа добиться необходимого мне поведения.

Коллеги, уже 9 июля ждем вас в офисе КОРУСа в Петербурге, где мы поделимся практиками в области корпоративной культуры, ценностей, вовлеченности и HR-бренда. Вас ждут реальный опыт и честный диалог, а еще – фуршет, нетворкинг и, конечно, экскурсия по офису.

Своим опытом поделятся:

👤 Александр Семенов, CEO – как ценности становятся частью бизнеса и корпоративной культуры.
👤 Евгения Миклуш, руководитель направления HR-аналитики – как измерять вовлеченность и понимать, что ценности действительно работают.
👤 Мария Ленкина, руководитель направления развития бренда работодателя – геймификация, внутренняя валюта и развитие HR-бренда.
👤 Татьяна Кульбякина, менеджер корпоративных программ развития – роль амбассадоров и внутренних сообществ в развитии компании.

Где и когда?
9 июля, 18.00-21.00
Санкт-Петербург, ул. Оптиков, д.4, корп. 3, БЦ «ЛАХТА-2» (ст.м. Старая Деревня)

🟡 Регистрация

При внедрении ИИ-технология вторична: сначала нужно договориться о реальности

Алексей Мезенцев, руководитель AI Lab ОТП Банка, выступил на Молодежном дне международной конференции «Теория игр и Менеджмент» (GTM 2026). В конференции также принял участие известный российский математик Алексей Савватеев и представители других банков и компаний. Спикер ОТП Банка рассказал, почему хорошие ИИ‑инициативы терпят крах на старте и какую ошибку совершают компании при автоматизации.

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

«Сначала нужно договориться о реальности, правилах и выигрыше. Проблема не в модели, а в том, сколько реальности ей доступно», — отметил он.

Опасной зоной руководитель AI Lab ОТП Банка назвал расхождение между официальными регламентами и реальной работой сотрудников. Слепое программирование формальных инструкций может не улучшить, а наоборот, ускорить неверные маршруты.

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

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

«Приоритет — это очередь гипотез, которая оценивается в деньгах. Задача — за минимальные деньги проверить эффект для бизнеса. Если мы не можем доказать ценность идеи, мы должны расставлять приоритеты не по масштабу будущего проекта, а по скорости проверки гипотезы», — объяснил представитель ОТП Банка.

Главное условие успеха: внедрение ИИ работает только тогда, когда выгоду получает каждый участник процесса от клиента до ИТ‑департамента.

«Мы внедряем не модели. Мы меняем правила игры. Идею нужно продать каждому участнику игры», — резюмировал он.

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

Откуда модель вообще узнаёт, что ошиблась? Именно с этого, как мне кажется, и стоит начинать изучение машинного обучения. В новой части книги я попытался объяснить это максимально просто и без фраз вроде "нейросеть сама обучается". Разбираем, что такое ошибка, почему она превращается в loss-функцию, зачем вообще нужны MSE и Log Loss, и как несколько строк математики становятся тем самым сигналом, который заставляет модель становиться лучше. Loss-функции являются центральным механизмом обучения современных моделей машинного обучения.

Если давно хотели понять, что происходит "под капотом" современных AI-моделей – буду рад, если почитаете.

📖 https://apphp.gitbook.io/ai-dlya-php-razrabotchikov-intuitivno-i-na-praktike/chast-ii.-obuchenie-kak-optimizaciya/2.1-oshibka-loss-funkcii-i-zachem-oni-nuzhny

Cтaтья «BotSharp изнyтpи: ищeм cлaбыe мecтa в кoдe ИИ‑плaтфopмы нa.NET»

Пpинятo cчитaть, чтo в AI и ML бeз Python никyдa, a.NET — этo иcключитeльнo иcтopия пpo enterprise, вeб‑paзpaбoткy и гeймдeв. Ho пpoeкт BotSharp гoтoв пocпopить c этим cтepeoтипoм, пpeдлaгaя ИИ‑плaтфopмy нa экocиcтeмe Microsoft.

Mы peшили зaглянyть пoд кaпoт BotSharp и пpoвepить, какие ошибки есть в его иcxoдном кoде.

Согласно новому исследованию, ИИ лучше человека в переписке с человеком проходит тест Тьюринга.

При предложении принять человекоподобный образ, GPT-4.5 был признан человеком в 73% случаев. Это значительно чаще, чем участники опроса выбирали реального человека.

Исследование: C.R. Jones, & B.K. Bergen, Large language models pass a standard three-party Turing test, Proc. Natl. Acad. Sci. 2026. DOI: 10.1073/pnas.2524472123

Источник: https://www.facebook.com/4everscience/

Хотел сделать крутую онлайн игру. Расскажу где всё пошло не так

Идея была простая до безобразия. Браузерная змейка но с живыми соперниками. Canvas, websocket, Node.js. Всё это я более-менее знал, казалось делов на пару выходных.

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

Ага.

Синхронизация это ад

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

Всё сломалось.

У одного игрока змейка уже повернула, у второго она ещё летит прямо. Столкновения каждый клиент считает сам по своей картинке мира. Один видит что убил соперника, второй видит что убил он. Оба правы по своей логике.

Полез гуглить. Нашёл что это называется authoritative server, client-side prediction, lag compensation. Понял что я вообще не туда смотрел когда проектировал. Думал займёт вечер. Потратил месяц и всё равно сделал через одно место.

Лобби которое я не планировал

Ок, физику перенёс на сервер. Теперь надо чтобы игроки могли найти друг друга, подождать, начать игру. Звучит как мелочь.

Это не мелочь.

Ожидание, старт, игра, конец, переиграть — каждое состояние надо синхронизировать. И самое весёлое это когда один игрок просто закрыл вкладку в середине партии. Что показывать второму? Кто победил? Как засчитать? Три вечера только на обработку разрывов соединения.

Читер за пять минут

Дал поиграть другу. Через пять минут он открыл консоль и начал отправлять серверу произвольные координаты. Змейка телепортировалась куда хочет. Я вообще не думал об этом когда писал архитектуру.

Что по итогу

Игра работает. Можно найти соперника и сыграть партию. Но код это такой клубок что я боюсь его открывать.

Главное что понял: онлайн игра это не игра плюс немного сетевого кода. Это совсем другая задача где сеть и есть основная сложность. Я недооценил это раз в десять минимум.

Код выложу на GitHub как разберу этот клубок. Пока стыдно показывать.

Кто делал нормальный мультиплеер в браузере, как решали синхронизацию? Потому что мои костыли мне самому не нравятся.

Прежде чем тащить ИИ в процесс, сначала разберись что вообще происходит

Приходил недавно в одну компанию. Ребята хотели автоматизировать обработку заявок от клиентов. Уже выбрали инструмент, уже договорились с подрядчиком, уже почти подписали.

Попросил показать как сейчас работает процесс.

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

Я спрашиваю: а что именно хотите автоматизировать? Они говорят: ну вот этот весь процесс, чтобы было чётко.

Это не автоматизация. Это ускорение хаоса.

Я уже видел такое несколько раз за последний год. Компания чувствует что что-то идёт не так, слышит везде про ИИ, решает что это и есть ответ. Но ИИ не чинит кривой процесс. Он его копирует и делает быстрее.

Правило которое я для себя вывел: если не можешь объяснить процесс новому сотруднику за 10 минут так чтобы он пошёл и сделал, не ломая при этом общую структуру, то автоматизировать ещё рано. Сначала объясни людям, выстрой свою систему, а потом уже автоматизируй.

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

Кто сталкивался с таким, когда приходили автоматизировать а оказывалось что сначала надо просто навести порядок?

🎓 День открытых дверей онлайн-магистратуры МФТИ «Управление ИТ-продуктами»

Если вы планируете развиваться в продуктовом менеджменте и хотите разобраться, как устроено обучение в онлайн-магистратуре, приходите на онлайн-встречу МФТИ.

На эфире расскажем:

▪️ Как устроена программа «Управление ИТ-продуктами».

▪️ Какие дисциплины изучают студенты и как проходят занятия.

▪️ Как организована работа над дипломом, проектами и взаимодействие с экспертами.

▪️ Какие карьерные возможности открываются перед студентами и выпускниками.

▪️ Как проходит поступление в 2026 году: документы, экзамены и подготовка.

Спикеры встречи:

— Юлия Соболь — заместитель руководителя Центра «Пуск» МФТИ.

— Елена Тупикова — экс-директор по продукту (CPO) в Яндексе, генеральный директор CPO.Agency, ментор и бизнес-коуч.

📅 Дата и время: 14 июля (вторник) в 18:00 (Мск)

💻 Формат: онлайн

Регистрация:

🔗 Telegram: https://t.me/mipt_events_bot?start=dl-1781626801729c428fcd8a

🔗 ВКонтакте: https://vk.com/app6379730_-224205661#l=24&auto=1

Астрономический научный центр модернизировал оркестрацию космического мониторинга с помощью ITFB Group

Астрономический научный центр (АНЦ) завершил масштабную модернизацию своей управляющей платформы. Интегратором выступила компания ITFB Group, которая помогла центру перейти на более надёжную и масштабируемую инфраструктуру, автоматизировать процессы разработки и обновления, а также гарантировать безотказную доставку критически важных данных о космических объектах.

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

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

Михаил Атрахимович, директор направления разработки ITFB Group, отметил: «В проекте для АО "АНЦ" мы использовали накопленный опыт создания высоконадежных платформ оркестрации бизнес-процессов. Основная сложность заключалась в том, что модернизацию необходимо было проводить без остановки уже работающей системы. В результате заказчик получил отказоустойчивую и масштабируемую платформу, готовую к дальнейшему развитию и увеличению объемов обработки данных».

Николай Савин, технический директор АО «АНЦ», добавил: «Сотрудничество с ITFB Group стало для нас важным этапом в развитии нашей системы оркестрации. Мы получили не только исправление текущих недочётов, но и чёткую дорожную карту, а также полный пакет эксплуатационной документации. Благодаря этому проекту мы уверены в надёжности и масштабируемости нашей платформы и готовы к дальнейшему расширению функционала».

В результате проекта АНЦ получил отказоустойчивую инфраструктуру enterprise-уровня, гарантированную доставку событий, автоматизированный релизный цикл и полный комплект эксплуатационной документации (мониторинг, алертинг, процедуры backup с RTO, регламенты при инцидентах).

Поддержка amoCRM может дать крутое решение, не описанное в документации, но оно не будет работать, потому что это ненастоящее решение.

Без негатива, но интересно, как это вообще могло произойти? У первого сотрудника поддержки была другая версия документации или на первой линии отвечает нейронка под галюнами?

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

Старт третьей рубрики ИТ-кроссворда уже через 30 минут 🦖

В 12:00 по московскому времени открываем новую рубрику ИТ-кроссворда — «Безопасность ML и AI». В публикации вас будут ждать вопросы об использовании ML в ИБ и новых типах угроз.

Зарегистрироваться →

👉 Отвечать на вопросы можно с 12:00 до 18:00 (МСК). Среди призов — комплекты эксклюзивного мерча Selectel и бонусы на аренду серверов.

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

В Anthropic раздают бесплатно доступ на полгода к Claude Max для разработчиков, кто делает коммиты и занимается Open Source проектами. Если поддерживаете важный пакет или сервис или активно участвуете в жизни открытых проекта, то можете подать заявку.

Требования к участникам открытых проектов, которые могут отправить заявку на получение бесплатной 6-месячной подписки Claude Max 20x:

• Авторы и сопровождающие открытых библиотек, пакеты с которыми насчитывают более 200 тысяч загрузок из каталогов, таких как npm, PyPI, crates.io и RubyGems, или которые используются как минимум в 500 репозиториях или в 100 зависимых пакетах.

• Ключевые разработчики крупных открытых проектов, имеющие право коммита или входящие в число сопровождающих. В качестве примеров уровня проектов упомянуты CPython, Rust, Node.js, Apache, CNCF, Kubernetes, ядро Linux, Django и Rails.

• Активные участники разработки, от которых было принято более 100 pull‑запросов в не аффилированные с ними проекты.

• Создатели сообществ, в разработке которых участвуют 20 и более сторонних разработчиков, от которых принимались pull‑запросы за последний год.

• Репозитории, применяемые в работе критически важной инфраструктуры (вес 0.4+ в рейтинге OpenSSF).

Открываю декодинг компьютерной графики фильма "Проект Конец Света" от Amazon (с Районом Гослингом)

При просмотре картины я решил воссоздать увиденное.

Первый эффект — анимация живых организмов.
Мне показалось в фильме используется визуализация шума. (монохром с анимацией transform Z)

Демо и исходники: https://t.me/mediapancake/1492

Всем привет!
Есть у меня такой вопрос к сообществу.

Дело в том, что еще в начале 80-х, будучи студентом и увлекаясь некоторыми разделами математики, я обнаружил странность в теории комплексных чисел. И устранил ее, тестируя на тогдашних ПМК по своей же написанной программе. И только недавно подумал, что хорошо бы оформить это в виде научной статьи. Ибо (что меня крайне удивило) я не нашел публикаций, где бы этот вопрос был решен кем-то другим.

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

1. Статья на русском и переводить на другие языки я не могу, да и зачем?
2. Статья не имеет отношения к моему месту работы, а значит никаких "актов экспертиз", "рекомендаций ученого совета" и прочей бюрократии у меня нет. Есть просто я как частное лицо.
3. Я не прошу гонорар, но и платить за публикацию тоже не имею возможности и желания. Вопрос чисто "для развития науки".
4. Я не знаю, каков практический эффект от моего "открытия", но чисто в плане теории его ценность, на мой взгляд, достаточно велика, чтобы оно было опубликовано.
5. В статье фактически нет списка литературы, потому что не на что ссылаться (базовые формулы общеизвестны).

Кстати, у меня есть и другие математические разработки, которые, по идее, тоже неплохо было бы опубликовать. Но непонятно где с учетом перечисленного выше. Статья сейчас оформлена в Ворде, объем 8 листов А4.

Может быть кто-то посоветует как быть, куда и как обратиться, где можно публиковать подобное и т.д.? Буду весьма признателен за конкретные рекомендации!

В первый раз в жизни, спустя 15 лет "ищу" работу. До недавнего времени работа меня находила сама. Возник некоторый поток мыслей по этому поводу.

Самое главное, насколько я понял, сейчас все резюме читает не человек, а ИИ, а на одну вакансию приходится от 10+ до 100+ человек (статистики у меня нет, по ощущениям так). Следовательно все вылизывают резюме в стиле "не просто навыки, а ценности". Художественные произведения в стиле как я провёл лет: ускорил всё на 50%, оптимизировал всё на 200%. Прямо сейчас открыл сайт визитку случайного человека. Цитирую: ускорение разработки на 30-70%, минус 45% критических багов в проде, в четыре раза сокращения времени онбординга, менторство, ревью и т.д. И всё это за пять лет работы.

Я оглядываясь на почти 15 лет своего опыта и не могу вспомнить конкретные кейсы, когда я ускорял разработку на 70% или уменьшал количества критических багов вдвое. Я хорошо помню, как я ронял прод, ошибочно стирал, а потом в поту восстанавливал таблицы в боевой базе, путался в часовых поясах, рефакторил или писал код неделями, который следовало бы сразу выкинуть, или часами и днями сидел над хитрым багом или собственной глупой ошибкой.

Синдром самозванца или на самом деле пора идти в сантехники? Но если все поголовно, практически каждый день ускоряет производительность на ~50%, почему такой софт ещё не улетел в космос?

А ответ кажется прост. Ещё ~5 лет назад никто не считал, на сколько он эффективен в процентах. Ты просто работаешь. Это твоя ежедневная обязанность "ускорять на 50%", "оптимизировать на 200%". Видишь кривую архитектуру из за которой каждый день сыпет баги - просто чинишь архитектуру. Видишь, что кто то наговнокодил (возможно ты сам, пол года назад) и запросы в БД замедлились в 2 раза, просто чинишь и попутно ускоряешь в 4 раза. Ты не фиксируешь это как своё достижение - это просто твоя работа, который ты горишь (а иногда и выгораешь) и за которую тебе платят. И тебе не надо отправлять производительность программы в космос и уменьшать критические ошибки на 45% (как это вообще считали?), если ты уже знаешь как написать код таким образом, что бы этого не понадобилось в обозримом будущем. Но что бы конкурировать с такими резюме нужны абсолютно другие навыки. Это уже не говоря про вайб-кодинг. Поэтому, возможно, всё таки придётся идти в сантехники.

За свою карьеру я успел попробовать Java, Python и ещё кучу всяких языков.

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

Наверное, потому что за много лет он стал для меня чем-то вроде дома. Открыл проект – и всё такое родное )). Не нужно перестраивать мышление, вспоминать особенности экосистемы или синтаксиса.

В общем, в какой-то момент эта мысль показалась настолько забавной, что я решил сделать небольшую музыкальную пародию на известную песню (старый хит 70х) – только про PHP и разработчиков, которые "ушли, но вернулись".

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

🎬 Видео: https://youtu.be/SoqAP4gSDac

Звучит знакомо?

Манифест контент-опса

Развивая тему ContenOps, я попробовал написать какой-то программный манифест. В DevOps философия базируется на принципах Agile, модели CALMS и концепции непрерывной поставки ценности. Если просто: писать код важно, нужно ещё важнее доставлять надёжно и отвечать за доставленное. Для контента развилка та же, только доставляем мы не код, а то, чему должны верить читатель и модель.

Что мы ценим. По мотивам Agile-манифеста разработки программного обеспечения

🔹Проверяемость важнее объёма.

🔹Правка системы важнее правки текста.

🔹Голос как контракт важнее голоса как чутья.

🔹Ответственность за выпущенное важнее скорости выпуска.

🔹Формализованное знание важнее знания в голове у редактора.

🔹Доверие читателя и модели важнее охвата.

При всей ценности того, что справа, левое мы ценим больше.

Три пути

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

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

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

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

И небольшой вывод

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

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

Подписывайтесь на канал, там пишу больше и чаще.

В три раза дороже, в пять раз важнее

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

Недавно появились первые результаты исследования, которое финансирует государственная программа Solar Sunshot. По предварительным оценкам, строительство предприятия обойдётся в 1,6-2,3 млрд долларов США. Для сравнения: в Китае за эти деньги можно построить завод мощностью 100-200 тыс. тонн в год.

Возникает логичный вопрос: Зачем вообще строить настолько дорогой завод?

Причин две:

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

Вторая – экономика. Страна добывает кварц и производит металлургический кремний, но затем отправляет это сырьё в Китай, а обратно покупает продукцию с высокой добавленной стоимостью. Логично, что австралийцы хотят оставить хотя бы часть этой цепочки у себя.

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

Неочевидный ответ «да» мне кажется более верным. Потому что получается интересный парадокс: Австралия готова заплатить в три раза больше не за более современный завод, а за возможность меньше зависеть от Китая. И, знаете, мне кажется, что именно этот аргумент в итоге и окажется самым весомым в том, чтоб правительство выделило деньги на строительство. Потому что не только Австралия хочет такой независимости. Несколько иностранных производителей ФЭПов (на словах пока что) готовы будут покупать австралийские слитки для той же диверсификации.

Так что вопрос, как мне кажется, состоит не в том, СТРОИТЬ ЗАВОД ИЛИ НЕТ, а в том, КОГДА он будет построен. Как то так…

Кстати, вот классный документик от ARENA по этой теме. Советую

---

Солар-Ньюс в телеграме - https://t.me/Solarnews