Теперь есть официальный integration guide, где показано, как ты можешь подключить MCP-сервер к AI-assistant’у и использовать его для нормального HITL workflow вокруг CV-аугментаций: подобрать pipeline, провалидировать его, отрендерить локальные previews, сравнить baseline и candidate, дать feedback вроде too_noisy:high и экспортировать финальный pipeline.
Приятно видеть, что проект стал частью экосистемной документации Albumentations. 🙂
AlbumentationsX MCP это конечно же не замена Python API, а assistant-facing review layer для тех случаев, когда ты хочешь быстрее и безопаснее работать с augmentation pipelines.
SimpleOne подтвердила совместимость своей платформы с РЕД ОС. Для заказчиков это значит, что запуск проектов в импортонезависимой ИТ-среде становится проще и предсказуемее.
Подтвержденная совместимость помогает:
сократить барьеры на этапе архитектурных согласований
упростить прохождение аудитов безопасности
быстрее запускать проекты по переходу на российское ПО
РЕД ОС широко используют в корпоративной и государственной инфраструктуре. По данным разработчика, систему уже применяют 12 000 компаний и государственных организаций, а общее количество инсталляций превысило 2 млн.
Economist вышел с обложкой на статью про возрастающее требование избирателей затормозить/запретить ИИ. Это волна только разгоняется, по сути луддиты 21 века, но так как политики часто используют подобные недовольства масс населения, то тему точно будут раскачивать.
Конкретно это выражается уже в начале запретов строить дата‑центры; справедливости ради надо сказать, что отдельные дата‑центры действительно уже портят жизнь конкретным городам Америки.
Уже обсуждаются прочие законы: прозрачность и маркировка ИИ‑контента, запреты и ограничения deepfakes, защита рабочих мест и «разделение выгод» и т. д.
Я думаю, все, кто хочет разделения выгод, получат себя в human in the loop 😀
Как все так ловко ИИ пользуются... Обзоры кода делают...
Не знаю, то ли я туповат, то ли невезучий, то ли кругом сказочники. Пытаюсь исследовать, какие новые интересные виды ошибок может находить ИИ в С++ коде, о которых не знает PVS-Studio. Claude Opus то нормально мне про интересные баги рассказывает, то на ровном месте с ума сходит.
Даю файл на вход, а он тревожно:
В присланном файле есть места, где содержимое обрезано/повреждено вставкой </context>, поэтому их я не рассматриваю как «баги кода» — это артефакты форматирования. Разберу реальные логические ошибки.
Шо? Какой context? Там максимум — это #include "context.hxx". Ну ладно, давай ошибки посмотрим.
Так, парочка сообщений по делу. Например, найден лишний аргумент при использовании функции форматирования.
addErrorMessage(&sciErr, API_ERROR_CREATE_ZDOUBLE_IN_NAMED_LIST,
_("%s: Unable to create list item #%d in Scilab memory"),
"createComplexZMatrixOfDoubleInNamedList", _iItemPos + 1, _pstName);
В строке форматирования два спецификатора %s и %d, а передаются три аргумента: funcName, _iItemPos+1, _pstName. Да, это баг. Про подобные паттерны PVS-Studio уже знает, хотя, возможно, нужно подсказать, что addErrorMessage — это printf-подобная функция. В целом, тут неинтересно, идём дальше.
// check a valid item
if (_iItemPos > iItem)
{
addErrorMessage(...);
return sciErr;
}
Здесь проверка «позиция валидна» использует >, хотя позиции 1-based, а iItem — количество элементов. Это выглядит как граничный дефект, но по сути _iItemPos == iItem допустимо, _iItemPos > iItem — ошибка. Это в порядке — правильная граница. Не баг. (Указываю, чтобы было понятно, что я это проверил.)
Так баг или не баг? Я три раза прочитал текст и посмотрел функцию с кодом. В итоге я не только не понимаю, есть ли здесь ошибка, но и не понимаю, что Claude пытается мне сказать.
Дальше ещё хуже шарики за ролики зашли.
Баг 5 (реальный): утечка в readCommonMatrixOfPolyInNamedList и др. — нет, это API отдаёт указатели наружу. Не баг.
Это всё описание пятого бага, больше ничего нет. Комментировать — только портить.
Я не понимаю, как на всём этом можно строить хоть сколько-то надёжные процессы автоматических обзоров кода, про которые в последнее время из разных утюгов вещают.
На сегодня мне ИИ достаточно. Пойду лучше пройдусь по парку, пока погода хорошая.
Представлен открытый проект Ghostprovider — терминальный инструмент для быстрого запуска GitHub‑проектов у себя на localhost.
Принцип работы проекта: предоставляется ссылка на репозиторий, а инструмент сам анализирует проект: ищет Dockerfile, docker‑compose, package.json, requirements.txt, Go/Rust/Python/Node‑признаки, определяет тип приложения и пытается развернуть его в Docker. После запуска показывает локальный URL, контейнеры, логи и дает управлять сервисами прямо из TUI: старт, стоп, рестарт, удаление. По сути это автоматизированная оболочка над git clone, docker build, docker run и docker compose up, только с автоанализом проекта и удобным интерфейсом в терминале.
Важно: инструмент реально запускает код из чужих репозиториев, поэтому случайные проекты лучше гонять в VM/песочнице и внимательно смотреть Dockerfile/docker‑compose перед запуском. Сам Ghostprovider выглядит прозрачным, но риск всегда в том, что именно вы через него запускаете.
С помощью ИИ можно автоматизировать почти что угодно, и именно поэтому многим сложно встроить его в повседневную работу. Непонятно, с чего начинать и какие процессы действительно стоит отдавать ИИ. В итоге идеи часто остаются на уровне «надо бы попробовать», но до реального использования так и не доходят.
Константин, специалист по ИИ в Naumen, рассказал, какие задачи стоит автоматизировать в первую очередь и по каким признакам понять, что процесс действительно подходит для ИИ.
Проверьте процесс по трем критериям
Перед тем как автоматизировать любую задачу, ответьте на три вопроса.
Боль. Насколько процесс раздражает, отнимает время или приводит к ошибкам?
Частота. Как часто вы его выполняете: каждый день, каждую неделю или раз в месяц?
Стоимость автоматизации. Есть ли понятные правила, по которым выполняется задача, или каждый делает ее по-своему?
Идеальный процесс для автоматизации выглядит так: часто повторяется, на него уходит много времени и это раздражает, выполняется по понятным правилам.
В первую очередь автоматизируйте работу с информацией
Практически любая задача, связанная с обработкой информации, — хороший кандидат для автоматизации.
Например:
Парсинг сайтов конкурентов, изучение технической документации, сбор данных из отчетов — в 90% случаев это можно доверить ИИ. Человек подключается только для валидации результата: проверить, не упущено ли что‑то важное, адекватен ли вывод.
Изучение документации — нет смысла читать 50 страниц документации вручную, когда ассистент справляется за минуту и выдает выжимку.
Любая работа с форматированием данных — привести таблицу к единому виду, объединить информацию из нескольких документов, удалить дубли или преобразовать данные в нужный формат.
Следующий шаг — база знаний команды
Во многих командах нужная информация существует, но хранится сразу в нескольких местах: в чатах, документах, личных заметках, папках или переписках.
Если собрать материалы по конкретным рабочим сценариям в единую базу знаний, можно создать ассистента, который:
отвечает на вопросы;
находит нужные фрагменты;
помогает новым сотрудникам быстрее разобраться в теме;
снижает количество однотипных вопросов внутри команды.
Важно, чтобы в базе была только полезная и актуальная информация. Чем больше шума и лишних документов, тем выше вероятность ошибок и неточных ответов.
Например, вместо поиска по нескольким чатам можно просто спросить ассистента: «Как у нас проходит релиз продукта?» или «Какие требования сейчас действуют для этой интеграции?».
А еще ИИ помогает командам лучше понимать друг друга. У каждой команды постепенно появляется свой язык: внутренние термины, сокращения, привычные формулировки. То, что разработчики считают очевидным, может быть непонятно продажам или менеджерам. Ассистент помогает быстрее переводить этот контекст между командами и снижает количество недопониманий в коммуникации.
Например, менеджер по продажам может попросить: «Объясни простыми словами, как работает эта функция, чтобы я мог рассказать о ней заказчику без технических терминов».
Создать такого ассистента сегодня можно несколькими способами
Для команды
Мы, например, создали платформу на базе Open WebUI. Любой сотрудник может создать ассистента, загрузить в него документы и открыть доступ коллегам. Ассистент помогает быстро находить информацию по вебинарам и рабочим материалам.
Для общей базы знаний
Можно подключить Claude Code к внешним репозиториям и использовать их как общую базу знаний команды. В таком сценарии ассистент получает доступ к рабочим материалам, заметкам и документам, которыми пользуются сразу несколько сотрудников.
Для личной работы
Можно собрать локальную базу знаний для себя: все рабочие материалы хранятся прямо на компьютере и никуда не передаются.
Главное — не пытаться автоматизировать все сразу. Найдите процесс, который часто повторяется, действительно мешает работать и выполняется по понятным правилам. Именно он обычно дает самый заметный результат.
Fable 5 вернули в Claude Code. Как не сгенерировать себе техдолг
Fable 5 снова доступен в Claude, и это хороший повод вернуться к более практичному вопросу: что именно делать разработчику с Claude Code, кроме генерации отдельных кусков кода.
В реальных задачах сложность обычно не в том, чтобы получить от модели отдельную функцию или заготовку сервиса. Гораздо важнее — превратить это в рабочий продукт: удерживать контекст, заранее задавать ограничения, проверять результат и не собрать после первого демо проект, который страшно поддерживать.
21 июля в 20:00 на бесплатном уроке разберём, как использовать Claude Code в разработке ИИ-приложений: от Telegram-ботов и агентов до внутренних сервисов, API и автоматизаций. Отдельно поговорим о работе с большими задачами — как дробить их на этапы, вести разработку итерациями, дорабатывать код и находить ошибки. Присоединяйтесь.
Все июльские разборы по ИИ, разработке, архитектуре и инфраструктуре собрали в дайджесте мероприятий.
Прилетело и в очередной раз и резануло по живому...
Системность - это ... (продолжите фразу)
Системность - это модное словечко из лексикона "эффективных менеджеров", которое скорее вводит в заблуждение, чем отражает суть.
Под системностью на бытовом уровне люди понимают наличие порядка, основанного на определенной логике.
Реже - наличие системного подхода, где любая ситуация воспринимается, как комплекс взаимосвязанных элементов и чтобы добиться желаемого результата следует рассмотреть все составляющие системы и надсистемы с прогнозом их поведения в зависимости от разных вариантов воздействия.
Вот только системный подход - это системный подход, а системность - это признак системы. И как признак системы это ...
НЕ ПРО ПОРЯДОК!
Системы вообще никакого отношения к порядку не имеют - любая система стремится к хаосу (тут умное слово - энтропия).
И только лишь работа с системой предполагает упорядочивание элементов и связей - чтобы во всём этом разобраться.
некоторый полет мысли имени очень искусственного как бы интеллекта
Тамагочи, но вместо котика – команда разработчиков. И она выгорает, пока вы читаете этот пост
Помните тамагочи? Пищащий брелок, который тихо умирал, если про него забыть на выходных.
Мы сделали такой же. Только вместо котика у вас разработчик и команда. Вместо «покормить» – 1-on-1, код-ревью, менторство и релизы. Забьете на пару дней – вернетесь к просевшему доверию и зреющему конфликту.
И живет это все прямо в терминале на сайте. Без установки, без регистрации, без «оставьте почту».
Тамагочи в терминале
Что это
team – симулятор тимлида в консольном режиме нашего сообщества. Не модалка с кнопками: вы открываете фейковый (но честно рабочий) терминал и печатаете команды.
team new – и у вас есть напарник-стажер и живая команда.
Дальше вы его растите от стажера до CTO.
Цель проста на словах: дорастить человека до уровня «тимлид» и выкатить пять релизов, не развалив команду по дороге.
Почему это тамагочи, а не просто игра
Вот тут начинается интересное. Состояние живет в localStorage и распадается в реальном времени.
Пропали на день – доверие просело, конфликт подрос, напарник задремал. Пропали надолго – рискуете вернуться к game over: команда либо выгорела, либо развалилась от конфликтов.
Это питомец, который ждет. И портится без вас.
Дилеммы из реальных споров
Периодически прилетает инцидент. Звезда принесла оффер +40% и мнется. Прод упал в пятницу в 18:00. Двое неделю спорят: монолит против микросервисов. Выбираете вариант – получаете последствия в метриках и в журнале команды.
И часть инцидентов подтягивается из живого бэклога вопросов нашего сообщества. То есть в игру попадают дилеммы, которые реально обсуждали практикующие тимлиды, а не выдуманные кейсы из учебника.
Как сыграть
Никакой установки. Открываете терминал и печатаете team:
А вам знакомо ощущение, когда тревога стала постоянным спутником жизни, когда привык к ней и просто перестаешь замечать?
У меня так было, причем очень долго. Последние лет пять тревожность была моей личной проблемой, с которой я пыталась как-то жить. Держала всё в голове, героически молчала, ночью раскручивала сценарии катастроф, гуглила симптомы, пережёвывала рабочие ситуации и делала вид, что всё нормально. Классика жанра: прод горит, но мы уверенно называем это «просто период такой».
В новой статье я попробовала посмотреть на тревожность через инженерную оптику: как на систему, где есть алерты, инциденты, мониторинг, ранбуки, команда поддержки, план отката и право не держать стопроцентный аптайм каждый день.
Но эта статья больше про мой личный опыт. И мне очень интересно, а как вы справляетесь с тревожностью? Что вам реально помогает, а что оказалось бесполезным советом?
Буду рада, если придёте в комментарии к статье и поделитесь своим опытом. Возможно, для кого-то чужой рабочий способ станет тем самым маленьким действием, которое сегодня не ухудшит ситуацию.
С помощью приглашённого эксперта Екатерины Рудиной, аналитиком департамента перспективных технологий "Лаборатории Касперского", мы разобрались, в чём сходство и различие таких систем с безопасным ПО, как соотносятся создание систем с КИБ и разработка безопасного ПО, чем полезен в работе специалистов по ИБ новый ГОСТ Р 72118—2025 "Защита информации. Системы с конструктивной информационной безопасностью. Методология разработки".
Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024
Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".
НЕкурс про РБПО
Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились.
Сравнение Claude Code Fable и Codex Open AI по ходу работы над одним и тем же проектом
Вчера, 1-го июля, программисты и активисты начали бурную трудовую неделю. А именно: вернулась модель Claude Fable 5 и она будет доступна в вольном режиме до (или по) 7 июля. Так что есть 7 дней, чтобы сделать буст своим проектам.
Я тоже не избежал этой участи и вот уже почти целый день делаю polishing своему текущему проекту мобильного приложения.
Что сказать про впечатления? - Ощущение вот того самого вайб кодинга, о котором говорил Карпаты. Говоришь модели что делать и она делает. Технических ошибок просто нет, от слова совсем. Есть ошибки архитектурные, но не существенные, исправляются одной-двумя итерациями.
И кстати, получилось сравнить с Codex'ом от Open AI, который решил попробовать на старте этого же проекта. Результат сравнения такой: Codex очень сильно подтянулся в работе с кодом, иногда даже кажется, что нет различий.
Но вот вокруг кода хуже: болтливые они оба, но у Codex больше какой-то разболтанности, разбрасывания в стороны. Особенно это видно на написании документации, пишет незначительные детали, теряет главное. И слабее держит инструкции.
Claude Code Fable в этом отношении гораздо чётче действует. Более жёстко держит инструкции, больше памяти, что характерно, помнит предыдущий и даже предыдущие чаты. Меньше разбрасывания на второстепенные детали, чётче фокус. Даже чек-лист у него выглядит проще, чётче и понятнее, чем у Codex.
Единственное, что может я так натаскал Claude. С другой стороны, не использую MCP, RAG, даже скилы и хуки. Зашил все в память, их там три: общая пользовательская, описание проекта и правила работы.
И напоследок обнаружил в Claude очень полезную функцию оценки загруженности контекстного окна.
Может она уже давно там была, о ней вроде писали, но что-то казалось, что это в CLI. А теперь оказывается её можно использовать и в декстопной версии. Думаю и другим пользователям это тоже пригодится.
Обычно смотришь, если чат начинает тормозить, значит пора. Или спросишь саму модель, но она обычно отвечает, что если на глаз, то загружена на 75%, но лучше начать новый чат. А теперь можно точно увидеть процент загруженности. Более того, можно даже увидеть чем именно загружено контекстное окно.
Для этого в чате Claude Code, в поле ввода достаточно ввести слэш команду - /context
Прикрепляю скриншот как это выглядит вживую
И ещё такое впечатление, что Claude Fable стал жечь меньше токенов за счёт какого-то более делового, но все ещё дружелюбного стиля общения.
Так что, удачи всем с проектами на этой бурной трудовой неделе!))
Во время обучения многим удобно иметь материал не только в формате уроков, но и в виде единого пособия, к которому можно быстро вернуться в любой момент.
Поэтому я решил подготовить книгу, полностью основанную на материалах курса. Она повторяет структуру уроков и позволяет легко закреплять пройденный материал.
Что представляет собой книга
Книга полностью соответствует программе курса и может использоваться параллельно с его прохождением.
Её можно использовать как:
офлайн-версию курса для повторения материала;
удобный конспект при выполнении практических заданий;
справочник для быстрого повторения основных конструкций SQL.
Если вы уже проходите курс, книга поможет быстрее находить нужную информацию и возвращаться к темам, которые хочется повторить.
Для кого она будет полезна
Так же, как и сам курс, книга ориентирована на тех, кто только начинает знакомство с SQL:
студентов IT-специальностей;
начинающих разработчиков;
будущих аналитиков данных;
тестировщиков;
всех, кто хочет разобраться в основах работы с реляционными базами данных.
Бесплатный доступ
Книга распространяется бесплатно.
Если вы проходите курс «SQL Введение», она уже доступна внутри курса в качестве дополнительного учебного материала.
Кроме того, книга опубликована на GitHub, где всегда можно скачать последнюю актуальную версию.
Буду рад вашим отзывам, предложениям и замечаниям как по курсу, так и по книге. Надеюсь, этот дополнительный материал сделает изучение SQL ещё более удобным и понятным.
Всем привет. У моего фреймворка Meta-Spider (про него можно почитать здесь) вышло большое обновление. Статью мне пока лень писать, так что будет пост.
Мы постоянно просим языковые модели «быть осторожнее» или «сказать, если не уверены». Работает это плохо: слова заходят, поведение не меняется. Причина в том, что неуверенность модели живёт в её внутренних активациях — там, куда текстовый промпт просто не достаёт.
meta-spider обучает тонкую обвязку (~2% параметров) поверх замороженной базовой модели. Она читает собственные скрытые состояния модели, сжимает их в «когнитивные токены» и впрыскивает обратно через cross-attention с вратами. В итоге модель отвечает уверенно там, где знает, и отказывается / идёт искать / уточняет — там, где нет. Веса базы при этом не меняются вообще.
Главный результат: латентный канал бьёт промпт
Отказ на неотвечаемом вопросе: текст-промт сдвинул с 0.07 до 0.07 — то есть вообще никак. Обвязка — до 0.87.
Поймано собственных ошибок базы: текст-промт 14%, обвязка 78%.
Просто попросить модель быть неуверенной — почти не двигает её. Обвязка двигает в разы, потому что работает с сигналом, до которого промпт не дотягивается.
Важный нюанс методологии, на котором мы сами споткнулись: читать латентный сигнал надо тем каналом, в который обвязка обучена — она генерит фразу-отказ, а не выбирает искусственную «UNSURE»-опцию. С кривым ридаутом обвязка выглядит инертной (это был наш баг).
Три новые фичи
🎚️ Ручка неуверенности. Инъекция — один регулятор времени исполнения: крутите вверх для осторожности, вниз для уверенности, в минус — инверсия. Микшерный пульт для поведения. gain 0→1.5 плавно крутит долю отказов ~2%→51%.
🐕 Сторож. Иногда не нужно менять вывод — нужно просто знать, что модель не уверена. Лёгкая проба читает этот сигнал и позволяет сходить в RAG / переспросить / эскалировать, не трогая генерацию (постоянная инъекция портит длинную генерацию, а чтение — нет).
UPD (Забыл добавить): Помимо этого сторож чинит многоступенчатую генерацию (например когда модель кодит), до этого периодические иньекции приводили к значительной деградации, притом на QA это не заметно, потому что модель генерит сама немного токенов. Сторож позволяет усиливать сигнал неуверенности только в нужные моменты, от этого количество иньекции значительно снижается, и не происходит деградирующего самоусиления.
🏭 Фабрика обвязок. Одна команда собирает общую обвязку неуверенности под любую базу:
metaloom build-universal --model-name N --quantization nf4 --suite suite.json --eval --export-gguf
На агентном суите из 6 осей это единственный вариант, не провалившийся ни на одной оси — калибрована по всему пространству решения, а не просто «переученная отказываться».
Чем практично
База заморожена, обвязка ~2% модели, весь цикл collect→train→eval прогоняется на ноутбучной GPU с 4 ГБ (nf4 + срез-тренер), а деплой — в llama.cpp на CPU через маленький GGUF-sidecar. GPU на инференсе не нужен.
Стоит заметить, что это про калибровку, а не про сособности. Модель умнее не становится — обвязка вытаскивает уже существующий внутри сигнал неуверенности и превращает «ответить наугад» в «ответить, когда уверен». Как начать
Есть CLAUDE.md. Рекомендую для использования фреймворка поначалу использовать ИИ-агента, способоного к продвинутому рассуждению в кодинге (Codex, Claude Code, DeepSeek V4 Pro через агентный движок и провайдера, которых вы предпочитаете), чтобы быстро опробовать и проверить его возможности.
В феврале этого года Питер Штайнбергер, создатель OpenClaw, присоединился к команде OpenAI и перебрался в Сан-Франциско. Питер всё так же работает над своим автономным агентом на больших языковых моделях, попутно пытается найти жильё (он до сих пор живёт в отеле и приценивается к перегретому рынку недвижимости в городе), но также продолжает заводить полезные знакомства и просто посещать разнообразные мероприятия. К примеру, на днях он появился на выступлении OpenAI Developers на AI Engineer World’s Fair — большой конференции для инженеров, которые уже собирают и выкатывают системы на искусственном интеллекте в продакшн.
Это не значит, что личный микроблог Штайнбергера — просто перечисление недавних встреч и выступлений вперемешку с анонсами новых версий OpenClaw. Питер умудряется находить в своём плотном графике время вести интересный личный дневник и репостить чужие мемы. Иногда он и сам выкладывает что-то любопытное.
Известно, что лимиты Codex часто (иногда по несколько раз в месяц) внепланово сбрасывают. Обычно это выглядит так: Тибо Соттьо, главный по Codex в OpenAI, объявляет, что в приложении была ошибка учёта использования, и её закрыли, поэтому в качестве извинений недельные лимиты были у всех сброшены вне очереди, а также добавлен один сброс, который пользователь может вызвать сам.
Штайнбергер показал шуточную кнопку этих самых сбросов недельных лимитов Codex. Где такой экспонат выставлялся (на одном из мероприятий или это фотокарточка из офиса OpenAI), Питер не уточняет.
Закон Йеркса — Додсона в психологии утверждает, что наилучшие результаты достигаются при средней интенсивности мотивации. Упоминание этого закона периодически встречается при описании стратегий управления персоналом.
В статье ‘Йеркс-Додсон: Закон на все времена года’ содержится описание исторических событий, начиная со статьи Йеркса и Додсона 1908 года. История достаточно поучительная. Йеркс и Додсон проводили эксперименты с крысами по прохождению лабиринта. В лабиринте имелось два выхода, один правильный, а другой неправильный. При попытке крысы выйти из неправильного выхода следовал удар током, интенсивность которого повышалась. Таким образом в исходных экспериментах речь шла не о мотивации, а о наказании. При этом Йеркс и Додсон были удовлетворены описанием в духе бихевиоризма и у них не возникало желание трактовать результаты в психологических терминах.
Первая статья с результатами на людях появилась в 1930 году, но в 30-х годах произошел существенный пересмотр концепций, связанных с обучением. Вместо наказания на первое место вышла мотивация и производительность. Это потребовало новых формулировок и новых постановок экспериментов. Исследователи этого времени были знакомы с статьями Йеркса и Додсона, но постепенно начал происходить процесс замены терминов. В любом случае до 1955 года подобные закономерности не рассматривались в качестве основополагающего принципа.
В конце 1950-х годов были проведены новые эксперименты на новом уровне (планирование эксперимента + надлежащая статистическая обработка). Питер Бродхерст в 1959 году заявил о возрождении закона Йеркса-Додсона на новых основаниях. Это совпало с введением в ход Дональдом Хеббом концепции возбудимость (arousal) и связанной с ней колоколообразной кривой. Интересно отметить, что Хебб в своей статье 1955 года не упоминал Йеркса и Додсона, но для других сходство было очевидным и процесс пошел.
Далее в статье говорится о том, что разные группы используют достаточно разные факторы при представлении колоколообразной кривой, и что до сих пор нет полного согласия о том, что же эта кривая представляет. Видимое единство в одном - в убеждении, что используемое представление восходит к Йерксу и Додсону, и что все это является выражением единого закона Йеркса-Додсона.
В заключение несколько слов про Джона Додсона. Его научная карьера сложилась не столь удачно, как у Йеркса, что показывает название статьи 2011 года ‘Что же случилось с Джоном Додсоном?’ Додсон во время работы над статьей 1908 году делал диплом у Йеркса. Оказалось, что в архиве последнего сохранилась переписка с Додсоном, в которой были просьбы помочь рекомендациями при устройстве на работу в тот или иной университет. Йеркс старался помочь Додсону, хотя его характеристики говорили о том, что таланты Додсона находились на посредственном уровне. В качестве плюса Йеркс отмечал хорошую работоспособность при выполнении экспериментальных исследований.
В заключение приведу цитату Йеркса, связанную со статьей Додсона, которую тот хотел опубликовать в 1931 году и попросил содействия в этом. Йеркс согласился и после получения статьи сразу же послал ее редактору со словами, что он не полностью удовлетворен ее содержанием, но поскольку статья короткая, то вполне можно ее опубликовать. Письмо к редактору завершалось такими словами:
‘Если бы у меня была свобода переписать статью, и я был бы готов посвятить этому время, я мог бы сильно улучшить ее форму и историческую перспективу.’
По-моему эта цитата прекрасно показывает закон Йеркса-Додсона в действии.
Karl Halvor Teigen, Yerkes-Dodson: A law for all seasons. Theory & Psychology 4, no. 4 (1994): 525-547.
Thomas Brothen. What ever happened to John Dodson? History of psychology 15, no. 1 (2012): 100-105.
Разработчики EVE Online выложили исходный код игры. Студия Fenris Creations известная ранее как CCP Games полностью открыла исходный код своего движка Carbon Platform, на котором работает знаменитая космическая MMO.
Разработчики не стали ограничиваться простыми утилитами и выложили в открытый доступ самые важные и сложные компоненты движка:
Trinity — графический движок, отвечающий за всю визуальную составляющую и рендеринг;
Destiny — физический модуль и систему поиска путей, которая позволяет просчитывать масштабные космические баталии с участием тысяч игроков одновременно;
Базовую архитектуру, связывающую все элементы системы воедино.
Большая часть компонентов Carbon Engine опубликована под максимально свободной лицензией MIT, которая разрешает бесплатное использование, модификацию и распространение кода, в том числе и в коммерческих целях.
Релиз ≠ деплой: почему прод падает именно после обновлений
Большинство крупных инцидентов происходят сразу после релиза. Не во время нагрузочного теста, не в случайный вторник — а именно тогда, когда команда только что что-то выкатила и выдохнула. Почему так, если всё прошло тестирование?
В новом выпуске «В SREду на кухне»вместе с Артёмом Гетманским, техруком юнитов в Авито, и Андреем Мухиным, TechLead из MWS, разобрались: что вообще считается релизом, чем он отличается от деплоя — и как не превратить каждое обновление в рулетку.
Что на повестке
Оказывается, релиз может сломать прод даже без единой строчки нового кода — и это не баг, а особенность современных систем. Разбираем, как Feature Flags, Canary, Blue-Green и Rolling-стратегии помогают снизить риск, когда hotfix тоже считается релизом и что с этим делать, и как error budget влияет на то, насколько смело команда вообще решается катить изменения.
Отдельно досталось вопросу, должны ли SRE участвовать в продуктовых релизах — и у участников выпуска на этот счёт нашлись весьма конкретные мнения.
