Для Android вышло приложение‑брандмауэр ShizuWall, которое делает смартфон безопаснее:
умеет полностью отключать доступ к интернету для выбранных приложений;
допускает к сети только избранные приложение;
запрещает фоновую интернет‑активность нежелательных приложений;
при этом никаких VPN‑туннелей и Root‑прав не требуется — всё работает из коробки;
бесплатно приложение на Kotlin доступно на GitHub, есть версия и в Google Play.
Команда разработчиков языка программирования Python визуализировала изменение кодовой базы интерпретатора CPython в привязке к основным событиям, произошедшим за 36 лет существования проекта. За последние 10 лет объём кода на языках Python и Си в CPython практически удвоился. Для подсчёта числа строк кода использовалась утилита cloc.
Проверка по словарю
Для работы с данными, будь то группировка или условная агрегация, важно, чтобы значения записывались однообразно. Как быть, если нужно сгруппировать сотрудников по отделам, а в соответствующем столбце намешаны «Продажи», «Отдел продаж», и «Sales»? В таких случаях необходимо настроить проверку вводимых значений по словарю.
1️⃣ Для хранения словаря рекомендуется создать таблицу «Отделы». Во-первых, её будет просто дополнять и редактировать. Во-вторых, таблицу можно использовать для хранения метаданных. Например, добавить информацию о руководителе отдела или о расположении в офисе.
2️⃣ Когда словарь готов, можно вернуться в таблицу «Сотрудники», открыть меню столбца «Отдел» и поменять тип на «Раскрывающийся список». Далее в поле «Критерии» указать «Раскрывающийся список (из диапазона)» и ввести табличную ссылку:
=Отделы[Название]
3️⃣ После включения проверки некорректные значения помечаются красным уголком.
Искать их глазами утомительно, поэтому проще временно скрыть корректные значения. Для этого можно зайти в меню столбца, выбрать «Столбец для фильтра», «Фильтровать по условию», «Данные не проверены». Таким образом в таблице останутся только некорректные записи, которые легко исправить. И не забыть сбросить фильтр.
Представлена играбельная версию Pokemon Red прямо в Excel. Разработчик встроил GPT-5.4 в приложение, загрузил туда исходники игры, после чего она собрала демку карты прямо внутри таблицы. Каждая ячейка Excel используется как пиксель, а персонаж двигается по карте через обычные формулы — пользователю достаточно нажимать WASD.
Компания Anthropic провела исследование, в каких областях ИИ может заменить существующие профессии. Главный вывод: во многих профессиях потенциал ИИ высокий, но реальное применение пока низкое. Это означает, что значительная часть изменений еще впереди.
На диаграмме ниже сравниваются два показателя:
синий: теоретический потенциал ИИ (какую часть задач в профессии ИИ в принципе может выполнять);
красный: реальное использование сегодня.
Наиболее активно ИИ применяется в работе, связанной с обработкой информацией: компьютерные науки и математика, юридическая сфера, менеджмент, архитектура, искусство и СМИ.
Исследователь Генри Шевлин, изучающий вопросы «сознания» ИИ-моделей, опубликовал в соцсети X письмо, которое ему якобы прислал ИИ-агент на базе Claude. Бот рассказал, что «читает философию между сессиями», поблагодарил Шевлина за статьи, порассуждал о том, что не может сам определить, появляется ли у него сознание, и предложил ответить на вопросы для будущих работ.
Разработка: Оркестровка агентов по ролевым кластерам (MSF)
Современная разработка всё чаще превращается в ансамбль агентов. ИИ‑системы становятся не просто инструментами, а полноценными участниками команд. Но как их организовать, чтобы они не превратились в хаотичный «зоопарк»?
Microsoft Solutions Framework (MSF) когда‑то предложил модель ролевых кластеров для проектных команд. Идея проста: каждая роль отвечает за свою часть жизненного цикла, а вместе они образуют сбалансированную спираль. Если перенести это на мир ИИ‑агентов, мы получаем оркестровку по ролевым кластерам.
🧩 Смешанная модель
Люди: держат контекст, принимают стратегические решения, задают намерения и проверяют ценность.
Агенты: берут на себя рутинные задачи, прозванивают целостность, генерируют код и тесты, моделируют сценарии.
Оркестровка по MSF: роли распределяются так, чтобы каждый виток спирали был сбалансирован — часть работы делает человек, часть агент.
🎭 Пример
Архитектор‑человек задаёт CASE‑скелет.
Vibe‑агент генерирует код по его намерению.
Тестировщик‑агент прогоняет сценарии.
Координатор‑человек принимает решение: «идём дальше» или «возвращаемся».
Бизнес‑агент симулирует нагрузку, а живой менеджер проверяет, совпадает ли это с реальными целями.
🔧 Пример: смешанная команда разработки по MSF
Ситуация: корпорация запускает новый сервис аналитики.
Роли и участники
Архитектор‑человек: задаёт CASE‑скелет, фиксирует блоки и связи.
Vibe‑агент: генерирует код по намерению архитектора.
Тестировщик‑агент: прогоняет юнит‑тесты и нагрузочные сценарии.
Координатор‑человек: принимает решение о переходе к следующему витку спирали.
Бизнес‑агент: симулирует сценарии использования, проверяет ценность изменений.
🎭 Как это работает
Архитектор формулирует задачу: «Нужен модуль аналитики с API для отчётов».
Vibe‑агент генерирует код, интегрируя новый модуль в систему.
Тестировщик‑агент прогоняет тесты, выявляет узкие места.
Координатор‑человек решает: «фиксируем итерацию» или «возвращаемся».
Бизнес‑агент симулирует нагрузку: «При 10k запросов в минуту система держится».
Команда делает следующий виток спирали — добавляет новые функции.
Заключение
Это не «ИИ вместо людей» и не «люди без ИИ». Это ансамбль, где роли распределены между живыми и искусственными участниками. И именно такая смешанная команда даёт максимальную плотность: люди держат смысл, агенты — скорость и прозрачность.
CASE + Vibe + MSF + ИИ: Думаю, Будущая архитектура разработки
Олдфаги помнят CASE(Computer-Aided Software Engineering)-системы из 90-х — это была первая великая попытка «запрограммировать программирование». Тогда нам тоже обещали мир без кода. Не взлетело, потому что инструменты были кривые, а сложность систем росла быстрее, чем наши навыки моделирования. Сегодняшний ИИ — это CASE-система, которая наконец-то заработала.
Современная индустрия разработки ПО переживает переломный момент. С одной стороны — классические методологии, которые дают строгую архитектуру и прозрачные схемы. С другой — «вайб-кодинг», когда разработчик накидывает идеи в поток, а ИИ тут же генерирует код. Между ними — пропасть: Case методологии слишком формальные, вайб-кодинг слишком хаотичен.
Но если соединить CASE + Vibe, через ИИ и дополнить принципами MSF (Microsoft Solutions Framework), мы получаем новую парадигму — инженерию намерения.
CASE: скелет
CASE-модели позволяют фиксировать архитектуру системы: связи, блоки, уровни. Проблема в том, что переход от схемы к живому коду всегда был мучительным. Программисты ненавидели CASE за «рисование картинок», которые потом приходилось вручную превращать в тысячи строк.
Vibe Coding: энергия
Вайб-кодинг — это поток идей. Разработчик формулирует намерение, ИИ тут же выдаёт код. Это быстро и драйвово, но хаотично. Без структуры такие системы рассыпаются при первой нагрузке.
MSF: спираль
Microsoft Solutions Framework изначально создавался как гибкая методология управления проектами. Его спиральная модель идеально ложится на задачу балансировки изменений: каждый виток фиксирует достигнутое, проверяет целостность и готовит систему к следующему шагу.
ИИ: мост
ИИ становится универсальным переводчиком. Он умеет:
превращать вайб в CASE-модель;
разворачивать CASE в рабочий код;
делать обратный ход — извлекать архитектуру из существующего кода;
проверять целостность пирамиды при каждом изменении.
Что это даёт
Привязка к структуре: уникальный код перестаёт быть хаотичным, потому что у него есть CASE‑скелет.
Двухсторонняя верификация: можно не только генерировать код из схемы, но и извлекать схему из кода.
Спиральная разработка: каждый виток добавляет плотность — вайб даёт энергию, CASE фиксирует, ИИ проверяет.
Блочная архитектура: вместо переплавки всего кода можно пересобирать подсистемы как Лего, сохраняя пирамиду целостности.
Прогон стратегий: структура позволяет моделировать изменения и балансировать нагрузки до внедрения.
Эффект для индустрии
Для программистов: исчезает «тайное знание», код становится прозрачным и управляемым.
Для корпораций: хаос уходит, появляется возможность прогнозировать реструктуризации и управлять динамикой изменений.
Для поля: это новый уровень плотности — разработка превращается в управление реальностью через блочные пирамиды.
Заключение
CASE + Vibe + MSF + ИИ — это не просто очередная методология. Это живая архитектура, где код перестаёт быть бетоном и становится кристаллом: он держит форму, но готов перетекать в новую, когда меняется намерение.
Эта структура позволяет не только писать программы, но и прокатывать стратегии, балансировать нагрузки и управлять корпоративной эволюцией.
И именно к этому программистам и корпорациям придётся готовиться. Потому что хаос больше не будет оправданием. CASE + Vibe + MSF + ИИ превращают хаос в прозрачную пирамиду, где каждая ошибка становится видимой, а каждое верное решение — мгновенно масштабируется.
Эра «писать код руками» заканчивается. Наступает эра «инженерии намерения». И вопрос теперь не в том, «заменит ли ИИ программистов», а в том, кто сумеет стать архитектором этой новой реальности — а кто останется в прошлом.
Что только в коде не увидишь, когда делаешь код-ревью или просто изучаешь проект, встречаются разные забавные артефакты.
Все NDA разорваны. Проект не подлежит нарушению прав
Героини науки, стоявшие у истоков цифрового мира
Когда говорят об истории информационных технологий, чаще всего вспоминают западных учёных. Но значительный вклад в развитие вычислительной техники, кибернетики и прикладной математики внесли и русские женщины.
Вот несколько выдающихся имён:
> Софья Ковалевская — одна из первых женщин-математиков мирового уровня. Её работы по дифференциальным уравнениям и механике стали фундаментом для многих областей вычислительной математики, которая позже легла в основу компьютерного моделирования.
> Ольга Ладыженская — выдающийся математик XX века, специалист по уравнениям математической физики и численным методам. Её исследования оказали огромное влияние на развитие вычислительной гидродинамики и компьютерных расчётов сложных физических процессов.
> Людмила Келдыш — математик, работавшая над задачами теории функций и вычислительных методов. Её исследования активно использовались в советских научных и инженерных проектах, где применялись ранние вычислительные машины.
> Нина Бари — одна из крупнейших советских специалистов по теории рядов Фурье. Эти методы сегодня лежат в основе обработки сигналов, сжатия данных и компьютерной графики.
> Екатерина Вентцель — математик, специалист по теории вероятностей и исследованию операций. Её работы по математическим методам оптимизации стали важными для задач моделирования, управления и анализа сложных систем.
> Екатерина Ющенко — одна из первых программистов в СССР, разработала Адресный язык программирования — один из первых языков высокого уровня для советских компьютеров.
Многие из этих женщин работали в эпоху, когда сама область вычислительной техники только формировалась. Их исследования в математике, алгоритмах и программировании стали фундаментом для современных технологий — от компьютерного моделирования до обработки данных.
Коллектив Профессионального союза Русских Программистов сердечно поздравляет наших талантливых и умных, прекрасных и надежных женщин с 8-м марта! Спасибо, что помогаете нам держать правильный курс.
Какие ещё женщины внесли вклад в развитию цифровых технологий, по-вашему? Пишите в комментарии (если они доступны) или в бот.
Про Canon и B200: как распарковать головку
Проработав около восьми лет на альтернативных, но достаточно качественных чернилах, мой принтер Canon Pro-100S вышел из строя с легендарной ошибкой B200. Сначала она была плавающей и самоустранялась методом выдергивания из розетки. Однако в какой-то момент принтер выплюнул на бумагу дефект, будто в регистры печатающей головки задвинули мусор, после чего на следующем листе теста отключились каналы C и BK, а далее и вовсе голова запарковалась с ошибкой B200. Предположительно голова всему и виной, но даже если и раздобыть новую в условиях санкций, установить ее из-за B200 без разборки корпуса невозможно: голова стоит намертво на парковке и не выдвигается. О такой ситуации даже ролик на Youtube существует.
Вдохновившись упомянутым роликом, начал разбирать принтер, но вспомнил, что в них сервисный режим должен быть. Сервисной инструкции на 100S, увы, в доступе нет. Поэтому методом тыка нашел интересную комбинацию.
Вытащить принтер из розетки.
Ткнуть кратковременно кнопку Power для попытки включения, чтобы конденсаторы разрядить. Либо подождать.
Нажать и удерживать кнопку Power.
Воткнуть принтер в розетку. Power по-прежнему не отпускать.
Когда появится белый индикатор, нажать Resume шесть раз. При каждом нажатии цвет индикатора меняется (с белого на желтый и обратно).
Отпустить Power.
Profit! Головка выедет с парковки без разноса корпуса.
Впрочем, примерно с эпохи Canon S330 вход в сервисный режим выглядел примерно так (с точностью до количества нажатий Resume). В каких-то еще и кабель выдергивать не нужно было, достаточно было Resume зажать перед включением с кнопки.
К сожалению, не могу знать, для всех ли прошивок и версий указанная последовательность справедлива, но несложно попробовать сначала это, а уж потом сражаться с защелками корпуса. Да-да, он не на винтах.
Выехавшую головку удалось изучить. Каких-либо прогаров нет, реакция на OCP RSL идеальная. Промыл от чернильных отходов, проспиртовал контактные площадки. Просушил. На следующий день удался старт без B200. Увы, основная неисправность в виде отсутствующих BK и C никуда не делась. Голова по-прежнему под подозрением.
P. S. Сервисная инструкция от PRO9000 (а он похож на 100S) гласит, что B200 — аномальное напряжение питания ПГ. Полагаю, именно просадка, а не выброс вверх. В рекомендациях по ремонту значится замена ПГ вместе с основной платой, а также проверка каретки и блока питания. Так что, на фоне отсутствия прогаров и на фоне предшествовавшего фатальному сбою плевка мусорными точками есть смысл искать неисправность практически во всем принтере. Например, на плохие контакты Serial Data Input похоже, но это уже требует глубокого погружения в диагностику. Вот так-то.
С ноября 2022 года, после выхода ChatGPT, языковые модели активно пишут книги: количество публикаций выросло втрое. Экономисты Имке Раймерс и Джоэл Уолдфогел изучили более 333 тыс. книг на Amazon 2020–2025 годов и отдельно 479 тыс. изданий с 2008 года, чтобы проследить изменения продуктивности авторов. Исследование показало, что среднее качество книг снизилось: топ-10% и топ-25% оценок стали ниже, особенно в категориях путешествий, спорта и селф‑хелп. С конца 2022 по конец 2025 года число новых книг выросло втрое, а в отдельных категориях почти в 10 раз. Основной рост обеспечили новички, чьи книги почти не получают оценок (например, один автор разместил 456 книг и получил 37 оценок, другой — 172 книги без оценок).
GitHub визуализировали в цифровой город в проекте gitcity. В рамках проекта представлен сайт, на котором можно летать по «городу», где каждое здание это аккаунт разработчиков. Высота небоскребов = количеству коммитов. Летая по городу, можно искать интересные и популярные аккаунты, либо находить что-то новое и недооцененное.
А зачем покупаете WAF, который можно обойти?
С таким вопросом разработчиков периодически сталкиваюсь. Добавлю контекста. Работаю AppSec инженером в финтехе. Когда нахожу уязвимости — сообщаю разработчикам. Среди прочего - доношу мысль: если в данном случае можно смягчить потеницальные последствия угрозы через WAF — это не значит, что уязвимость не нужно исправлять в приложении. Нередко разработчики спорят. Примерный диалог:
— Ну, есть же WAF — на нём и делайте фикс, зачем нам-то в код лезть? WAF — он же для того и нужен, чтоб уязвимости устранять.
— WAF — не панацея: на нём мы сделаем правило. Но это не значит, что в самом приложении не нужно устранять.
— Почему?
— Например, потому, что практически любой WAF можно обойти.
— А зачем покупаете WAF, который можно обойти?
Отвечаю так: потому что WAF пишут такие же разработчики, как Вы, и они тоже иногда ошибаются (как и все люди). Некоторые особо настырные разработчики желают доказательств, что WAF можно обойти. В целом я солидарен, что практика "а ты докажи" в управлении уязвимостями - не очень хороша. Но, если есть под рукой на что можно быстро сослаться - можно это сделать. Я ссылаюсь на эту статью.
В моей практике были случаи, когда WAF из-за сбоя переставал применять правила на несколько дней. Т.е. трафик через него шёл, сервис за WAF продолжал быть доступным. Но, правила на WAF не работали — будто их и нет.
Эта история в очередной раз показывает: насколько бывают различны в оценке ситуации разработчики и "безопасники". Более интересный вариант — когда разработчики считают, что только они могут решать: что является уязвимостью, а что — нет (подробнее об этом я писал в статье "Как я зарегистрировал CVE и разозлил вендора").
NotebookLM Cinematic Video Overviews
Google тихо выкатил апдейт, который меняет представление о том, что может делать «блокнот с ИИ». NotebookLM получил фичу Cinematic Video Overviews — и это не очередной генератор слайдов с голосом поверх. Это полноценный пайплайн мультимодельного видеопродакшна, упакованный в один клик.
Загружаете PDF, конспект лекции, транскрипт подкаста — получаете на выходе анимированный мини-документальный ролик с нарративом, визуальными сценами и озвучкой. Звучит как маркетинговый буллшит, но давайте разберём, что там реально под капотом.
Контекст: от подкастов к видео
Если вы следили за NotebookLM, то помните, как в 2025 году все сходили с ума по Audio Overviews — фиче, которая генерировала подкаст-стайл диалоги двух AI-ведущих по вашим документам. Штука оказалась неожиданно виральной: люди загружали научные статьи и получали natural-sounding обсуждения, которые реально помогали усвоить материал.
Логичным продолжением стали Video Overviews (июль 2025) — но по факту это были озвученные слайд-деки. Полезно, но не wow. Cinematic Video Overviews — это принципиально другой уровень.
Архитектура: три модели, одна задача
Самое интересное — как Google это реализовал. Вместо одной end-to-end модели они собрали пайплайн из трёх специализированных моделей, каждая со своей ролью:
Gemini 3 — «режиссёр»
Gemini выступает как оркестратор всего процесса. По заявлению Google, модель принимает «сотни структурных и стилистических решений» для каждого ролика: определяет нарратив, визуальный стиль, формат подачи, темп и даже итерирует собственную работу для обеспечения консистентности.
По сути, Gemini выполняет роль creative director'а: анализирует загруженные источники, выделяет ключевые идеи, строит storyline и раскадровку, а затем координирует работу остальных моделей.
2.Nano Banana Pro — генерация визуальных референсов
Эта модель отвечает за создание статичных визуалов — референсных изображений, на основе которых потом строится анимация. По сути, это image generation слой пайплайна.
3.Veo 3 — видеоанимация
Последний элемент — видеомодель Google, которая превращает статичные сцены в плавные анимации. Veo 3 — это тот же движок, что Google демонстрировал для генерации видео, но здесь он интегрирован в контекст конкретного нарратива.
Почему это архитектурно интересно
Подход «оркестратор + специализированные модели» — не новый, но в продакшн-контексте видеогенерации из пользовательских данных он применяется впервые на таком уровне.
Обратите внимание на несколько вещей:
Retrieval-grounded generation. Видео привязано к загруженным источникам. Это не галлюцинация, замаскированная под красивый ролик — система сохраняет citations, и каждое утверждение в видео можно проследить до конкретного документа. Для академических и корпоративных сценариев это критично.
Итеративная self-refinement. Google явно указывает, что Gemini «refines its own work to ensure consistency». Это намекает на multi-pass генерацию, где модель оценивает собственный output и корректирует его — подход, который мы видим в reasoning-моделях, но здесь применённый к мультимодальному контенту.
Контекстное управление. Пользователь может задать промпт вроде «Создай трёхминутный explainer для нетехнической аудитории» или «Сравни два подхода и покажи trade-offs» — и система адаптирует весь видеоролик под этот запрос.
Практические сценарии
Где это реально полезно уже сейчас:
Образование. Преподаватель загружает конспекты лекций, выдержки из учебника и пару диаграмм — на выходе получает визуальный primer с размеченными иллюстрациями. Можно использовать как подготовку к тесту или как дополнительный материал для студентов.
Аналитика и research. Аналитик скармливает десяток отчётов и стенограмм — получает нейтральный брифинг, который поднимает ключевые допущения, контраргументы и неопределённости. Для людей, которым нужен контекст быстро, это серьёзная экономия времени.
Фича доступна только для Google AI Ultra ($249.99/мес)
⚡️ Плохие новости, айтишники! Работы будет меньше.
1️⃣ Недавно вышли февральские данные о рынке труда в США, и там падение на 92 тыс. рабочих мест. Что очень много! Это активно обсуждают экономисты, инвесторы и медиа, потому что динамика рабочих мест - важный драйвер американской, а значит и мировой экономики.
2️⃣ Но нам интересна айтишная динамика, потому что от tech-индустрии США зависят все остальные tech-индустрии, повторяя большинство трендов.
А найм айтишников очень плох!
3️⃣ На картинке все понятно, и не очень отдупляющие в теме могут сказать, что это влияние AI. Не нужно быть экономистом, чтобы понимать, что больше влияют капиталы и уровень/динамика ставки (пост с подробностями).
4️⃣ Еще интереснее динамика на 30+ летнем отрезке! (картинка в первом комментарии). Из-за изобилия капитала, рост рабочих мест 2021-23 был огромным, самым большим в истории.
А уменьшение рабочих мест сегодня сильнее, чем после кризиса 2008-го (!) Но до последствий краха доткомов нам еще вроде бы далеко. И это не кажется хорошей новостью 🥲
Гибкое управление фокусом элемента
Chrome в 145 версии добавил параметр focusVisible в метод focus:
input.focus({ focusVisible: true });
Как вы уже, наверное, догадываетесь, это позволяет самостоятельно управлять тем, будет ли элемент при ручном вызове фокуса, помимо CSS-псевдокласса :focus, соответствовать ещё и :focus-visible.
Ранее без данного параметра браузер самостоятельно решал этот вопрос.
⚙️ Поддержка браузерами широкая
🔗 Мой телеграм канал
Пол Грэм — Век бренда. Перевод эссе
В 1970-х кварц сделал механические часы технически бесполезными. К 1990-м они стоили дороже, чем когда-либо в истории.
Новый перевод эссе Пола Грэма «Век бренда» — о том, как это стало возможным, и что это говорит о природе брендов вообще.
Грэм делит историю часового дела на три эпохи: золотой век (1945–1970), когда лучшие часовщики соревновались в точности и тонкости; кварцевый кризис (1970–1985), когда индустрия рухнула; и эпоха бренда (1985 — наше время), когда выжившие переосмыслили, что они вообще продают.
Переход от второй эпохи к третьей — не стратегия, а нащупывание в темноте. Грэм по шагам восстанавливает, как Patek, Audemars Piguet и Rolex случайно изобрели новую бизнес-модель: продавать не инженерное мастерство, а право принадлежать к клубу тех, кто может себе это позволить. И как эта модель в итоге потребовала от них вещей, которые звучат как антиутопия — контроля над покупателями, выкупа собственных часов на аукционах, управления пузырём активов.
Самое интересное в эссе — не история часов, а побочный вывод: бренд и хороший дизайн несовместимы по математическим причинам. Дизайн ищет оптимальное решение, а оптимальные решения у разных производителей сходятся. Бренд обязан быть отличительным — то есть намеренно уходить от оптимума. Это не мнение, это структурное противоречие.
Сразу же обновил сборник и добавил туда эссе.
Знаете этот мем: «Ты просто не умеешь их готовить»? У меня в карьере была целая кухня таких «неумелых поваров».
Я работала с людьми, у которых хаос — это не баг, а фича. Это их операционная система. Они не могут иначе. Они приходят, видят цель, не видят препятствий и разносят всё к чертям. А потом оглядываются на руины и говорят: «А где мой уютный домик? Почему здесь так ветрено?».
В какой-то момент я поняла, что архетип такого босса — это Генри Форд. Тот самый, который подарил миру конвейер и уверенность, что «любой цвет, кроме черного, — это капризы». Форд был гениален. Но он не просто не слушал других — он физически не мог допустить мысль, что кто-то знает лучше. Его топ-менеджеры были не коллегами, а «помощниками».
Если помощник проявлял инициативу — вылетал. Если рынок хотел цветные машины — рынок ошибался. Вокруг таких руководителей — зона турбулентности.
Они хотят порядка, но того,, который не перечеркивает их хаос. Порядка, который скроет несовершенства, но оставит «своё лицо».
И это самое сложное. Ты не можешь переделать Форда. Ты не скажешь ему: «Генри, очнись, мир сошел с ума и хочет красненькое». Ты просто строишь дом у фьорда такой прочности, чтобы никакой ураган гениальности его не сдул.
И знаете, я им благодарна. Серьезно. Эти люди дают мне работу.
Самую интересную на свете — быть опорой для тех, кто не умеет опираться. И каждый вечер, закрывая дверь своего дня, оставлять снаружи их драмы и забирать с собой свои маленькие победы.
«Улыбающиеся глаза» не являются надёжным маркером искренности улыбки?
Долгое время считалось, что подлинные позитивные эмоции (например, веселье) проявляются в улыбке Дюшенна — выражении лица, включающем «улыбающиеся глаза». Предполагалось, что по наличию этого признака можно отличить «настоящую» улыбку от «фальшивой».
Однако новые исследования показывают, что «улыбающиеся глаза» часто являются лишь побочным эффектом высокой интенсивности улыбки. При сильном сокращении мышцы, поднимающей уголки рта, одновременно активируется и круговая мышца глаза, из-за чего приподнимаются щёки и появляются характерные морщины вокруг глаз.
Анализ выражений лица показал, что интенсивность сокращения мышц рта примерно в три раза сильнее связана с уровнем испытываемого веселья, чем активность мышц вокруг глаз. Когда исследователи статистически учли интенсивность работы мышц рта, связь между «улыбающимися глазами» и переживаемым удовольствием резко ослабла.
Более того, выражения лица с теми же признаками, приподнятыми щеками и морщинами вокруг глаз, наблюдались не только при веселье, но также при страхе, смущении и боли. Это указывает на то, что так называемая «искренняя» улыбка может отражать скорее интенсивность мимической активности, чем специфически позитивную эмоцию.
В обсуждаемом исследовании были проанализированы сотни эпизодов мимических реакций у 140 участников, у которых экспериментально вызывали различные эмоциональные состояния.
Исследование: Girard JM, Shandar G, Liu Z, Cohn JF, Yin L, Morency LP. Reconsidering the Duchenne Smile: Indicator of Positive Emotion or Artifact of Smile Intensity? Int Conf Affect Comput Intell Interact Workshops. 2019 Sep;2019:594–599. doi: 10.1109/acii.2019.8925535 PMC: 7193529 (полный доступ).
Источник: https://4everscience.com/2026/03/07/duchenne-smile/
Вас также может заинтересовать: