Ненавижу, когда на загадки не публикую отгадки. Поэтому вот. У капли относительно стекла две компоненты скорости: вертикальная (задана в условии) и горизонтальная (скорость авто относительно капли). Отношение скоростей здесь это тангенс угла alpha. Угол alpha, под которым капли размазываются по стеклу, чуть меньше 45 градусов. Значит, скорость такси чуть выше скорости капель. На деле примерно 35-40 км/ч.
Эта задачка была у меня в (лучшей физмат) школе в Уфе, в 10-м классе. Там че-то про Мюнхгаузена было. Так что не расстраивайтесь, если не решили, это для молодых и дерзких. :)

Расскажу, что получилось на проекте в ЦМФ

Возможно вы ожидали здесь видео про аналог пепси-колы, но нет. Что-то у нас получилось. На основной сети тезоса ребята написали смарт-контракт, который умеет ставить и матчить ордера. Да, получилось, что всё делается прямо в контракте. Поддержали лимитники и маркетные ордера. Написали очень примитивный фронтенд к этому всему. И забили.
Сайдчейн так и не появился, энтузиазм у ребят поугас, программировать на rust не понадобилось.
Стоит отрефлексировать этот проект.
1. На мой взгляд, у нас получилась ситуация "у семи нянек дитя без глазу": два ПО (один из них я), оба в какой-то момент понадеялись на другого и продолбали где-то сроки, где-то решения.
2. У нас не было толком трекера проекта, минуток со встреч и даже запланированные встречи часто ехали. Поэтому, если выпал разок, то уже потерял много контекста (а команда у нас была сильно распределённой, кто-то выпадал регулярно).
3. Коммуникация была в личках, а не в трекере или общем чате, поэтому сложно даже отследить, кто что сделал, почему пришли к такому решению, кто принял решение и т.д.
4. Использование хороших практик на работе, за деньги, в окружении привычных, удобных, всем знакомых инструментов не гарантирует, что вы будете применять эти же практики в условиях маленького учебного хаоса.

В общем, получилось скорее вопреки, а не благодаря, но, не сколько мне известно, это вообще единственный проект в этом потоке web3, который показал хоть какое-то готовое решение. Но это не точно 😁.

Оставлю тут рецензию на доклад Саши Ланцова на Jpoint'е

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

Тема достаточно сложная, въехать в неё непросто, особенно, если кристального понимания даже стандартной JMM в голове нет. Я ждал, что будет какой-то ассемблер, протоколы когерентности, топологии процессоров или по крайней мере барьеры памяти! В крайнем случае, думал я, можно как-то отвертеться абстрактными математическими serializability vs linearizability. Но нет! Вообще никакой дичи! Вся тема доклада раскрыта без использования сложноты.
Да, пожалуй, понимания "почему" не появится, но в инженерной профессии по-существу нужно только "как" (почему это в факультативном порядке). И вот в этом месте доклад не только дает хорошую интуицию, но и валит примерами, как из рога изобилия. Есть даже отдельный репозиторий на гитхабе, код из которого автор любезно погонял на x86 и ARM (ради такого дела даже купил Raspberry Pi).

Если вам хочется подглядеть, что там в конкаренси за пределом volatile, то must watch. Не только сможете наконец прочитать исходники дисраптора, но и гораздо лучше поймете, какие гарантии вы имеете, используя ставший уже классическим happens-before.

А я под впечатлением грузану немножко программерской духоты в этот канал. Держитесь.

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

Что мне просто бросилось в глаза, так это огромные пересечения представлений Сократа с этикой мировых религий. Аскеза, чистота помыслов, посмертный суд, чистилище, переселение душ в животных, припоминание прошлых жизней, вечная радость в раю и т.д. По Сократу попасть в рай можно только философу, который приобщал душу к божественному всю жизнь, ведь он размышлял о природе, о сути вещей, о вечном, о божественном. Раз думаешь о божественном, значит приобщаешься, становишься подобным. Подобное притягивания подобным. Что-то там такое... 😁

Короче, почитайте, умные вещи дедушка говорил.

Платон, кстати, жёстко издевается надо мной. Здесь речь про то место, которое я так толком и не понял.

serializability vs linearizability

Начнём с изянства. Есть такие математические понятия, с которыми вы могли познакомиться в книжке The Art of Multiprocessor Programming.

Что это такое?
Если программа обладает любым из этих свойств, то гарантируется, что _любой_ _результат_ выполнения программы можно объяснить _последовательным_ исполнением инструкций программы.
Пример.
Вот в java есть такие типы, как long и double, для которых на 32-разрядных версиях спецификацией не гарантируется атомарность записи. То есть у вас поток А писал число 2*10^10, а поток B писал число 20 в одну и ту же переменную условно одновременно. Может получиться, что в переменной по итогу окажется число 0. Ни поток А, ни поток B это число туда не писали. Значит, объяснить такое поведение программы последовательным исполнением команд нельзя. У такой программы нет ни serializability, ни linearizability.

В чем тогда разница?
serializable гарантирует только наличие _какого-то_ порядка последовательного исполнения инструкций (возможно, разного для разных наблюдателей), а linearizable — _одинакового_ для всех акторов.
Пример.
Знаменитый IRIW (independent reads of independent writes). Смотрите на прикрепленную картинку. Два потока пишут в две разные независимые переменные, а два других читают из этих переменных по очереди. В случае с serilalizability _может_ так получиться, что и первый поток прочитает (x=1, y=0), и второй (y=1, x=0), т.е. не существует какого-то одного глобального порядка исполнения инструкций, которым можно было бы объяснить такой исход. В случае с linearizability такое невозможно.
*Картинка нагло украдена у господина Шипилёва.

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

Про зарплатные вилки

Очень тяжёлая штука, указывать зарплатную вилку. Если, конечно, бюджетом управляешь ты, а не кто-то тебе сверху спустил стандарты. С одной стороны есть вот эта тема с утечкой информации, якобы компания больше знает об уровне зарплат (смотрит много кандидатов), а соискатель якобы не знает. И получается, что ассиметрия информации, надо выбивать вилку и вот это всё. Надо. Несомненно надо.
С другой стороны, когда указываешь вилку типа 250-400к в месяц, то любой, вообще каждый кандидат будет просить 400к. И будет уверен, что он достоин, как минимум, не меньше.
На выходе иногда получается, что компания либо просто отказывает кандидату, потому что могла бы предложить 300, а он просит 400 — больше разница. Либо предлагает кандидату 300, и тот в некоторых случаях принимает, а в некоторых уже всё, раз в вилке прочитал 400, будет искать эту зарплату на рынке, пока не переберёт все компании мира.
Такова человеческая натура, я тоже всегда только на верхнюю границу смотрю.

Вопрос праздный, у меня этой проблемы нет (пока?). Но как вы думаете, нужно выбирать вилку для указания в вакансии?

Про лоу перформеров

У нас на работе несколько месяцев как появились разные мероприятия для руководителей, где можно обсудить острые темы и обменяться опытом. В том числе анонимно. Насколько раз за последнее время всплывала тема "плохо работает, обратная связь не помогает, мотивация не помогает; ну или альтернативно: помогает волнами". Это ситуация, которая была у меня, к сожалению, уже несколько раз.
Давайте я обозначу здесь сразу какие-то очевидные вещи.
- Самая важная очевидная вещь. Нужно говорить с людьми. Если им не сказать, что они делают что-то плохо/медленно/не то, то они об этом не узнают.
- Вторая важная очевидная вещь. Разговаривать нужно конкретно по поступкам. Не "ты чет плохо работаешь", а "ты делаешь задачу Х уже на неделю дольше и всё ещё не готово". Не по персоналии.
- Третья очень важная очевидная вещь, которую часто забывают. Сначала узнать у сотрудника, как он видит ситуацию. Только потом рассказать, как видишь ты и _предложить_ помощь_.
- Четвёртая очевидная важная вещь, которую тоже забывают. После того, как обсудили план, че делать дальше, _убедиться_, что вы поняли друг друга одинаково. Проще всего попросить объяснить своими словами, что человек понял и что собирается делать.
- Пятая, не столь очевидная вещь. Нужно знать, что мотивирует конкретного сотрудника и пытаться это ему дать.

Все эти очевидные вещи в нормальном формате можно узнать в практикуме.

Теперь предположим, что вы всё делали, как написано в учебнике. Несколько раз. Но ТРЕНЕР, БЛОКИ НЕ РАБОТАЮТ. Тогда надо перестать жевать сопли и говорить с сотрудником о расставании. Все попытки дать ещё и ещё и ещё один шанс, какие-то там пряники и кнуты, возможно, будут помогать на _очень_ короткие промежутки времени. Но, во-первых, это издевательство над психикой сотрудника, постоянный стресс, отсутствие уверенности в завтрашнем дне. Во-вторых, это ужасающая куча геморроя, на который времени тратить придётся много, а эффекта будет мало.

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

Дочитал диалог "Протагор"

И преисполнился. Во-первых, это очень понятный диалог. Во-вторых, сложно не согласиться с его выводами. Почувствовал себя намного мудрее теперь.

Интересные наблюдения:
- если "апология Сократа" дала понимание, почему греческие философы зачастую прибегали к аскезе вообще; то "Протагор" подтверждает, что аскеза — это общепринятое в греческом обществе благо. Это сразу расширяет границы понимания университетского курса философии (не аспирантского, конечно), где куча аскетов, потому аскеза это круто 🤡
- греки практиковали голодание, как оздоровительную процедуру 🤔
- теперь полностью ясна концепция, что всё зло от незнания; что человек по природе своей не может осознанно деять зло. Я, кстати, с этим полностью согласен, от этой основы строится моя картина мира. Но из-за этого со мной редко кто согласен в дискуссиях на общественно-политические темы.
Именно из-за этого представления Платон потом говорит, что идеальные правители — это философы, т.е. люди, посвящяющие жизнь приобретению знаний.
- САМОЕ ГЛАВНОЕ ДЛЯ МЕНЯ. Даже мудрейший Протагор нем умеет читать, чито написано! Я очень сильно бешусь, когда люди читают не то, что написано, а то, что они хотят прочитать. Додумывают в контексте собственных мыслей, знаний и представлений, не задумываясь о таковых автора.
Это, кстати, проблема именно письменной речи, почему-то. Надо бы обдумать, почему так.
Справедливости ради, Протагор не смог прочитать довольно сложный кейс (в отличие от большинства людей в интернете), но сути дела это не меняет — читать, что написано, не умеет почти никто (я тоже), но у всех неумение на разных уровнях.

Суть ошибки Протагора следующая. Он рассматривает стих Симонида.

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

Там же, ниже по тексту, Симонид критикует Питтака:

Вовсе не ладным сдаётся мне слово Питтака,
Хоть его рёк и мудрец: добрым быть нелегко.

Простите, но думаю, что многие, как и Протагор, увидят здесь противоречие. Сам Симонид сначала говорит, что сложно стать хорошим, а потом критикует Питтака за слова, что трудно брать хорошим. Но противоречия здесь нет. TL;DR Симонид утверждает, что даже стать хорошим (будучи плохим) сложно, а уж быть хорошим (всё время) вообще невозможно. И Симонид считает, что не стоит осуждать неидеальных людей, потому что иначе придётся осуждать всех.

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

Какой вывод я делаю?
Нужно быть терпимее к тем, кто не умеет читать, что написано. Если уж даже мудрейшие не способны, то чего ждать от остальных. Буду стараться смиренно переносить эту боль впредь.

Про memory barriers

Опять не про психологию, а эти мои любимые компьютеры. Контент в кои-то веки c++ tolerant!

Сегодня снова про разницу между sequential consistency и release/acquire. Если забыли, в чем там прикол, то перечитайте презентацию с гитхаба Саши или статью Дага Ли. Многие продвинутые джависты, я уверен, читали jsr 133 cookbook. Там написано, как _можно_было_бы_ реализовать volatile записи и чтения (это sequential consistency) на разных архитектурах процессоров.

В этой статье есть несколько интересных моментов. Давайте их посмотрим поближе.
Первое. Рассматриваются барьеры между парами операций чтения и записи (load/load — между двумя чтениями, store/load — между чтением и записью, load/store и store/store). Это представление достаточно удобно для рассуждений (reasoning), но является абстракцией.
Второе. У x86 есть только одна инструкция-барьер — mfence, у power pc две: [lw]sync и hwsync; и вообще больше двух инструкций ни у кого нет. А абстрактных барьера — четыре. Наплодили тут!
Третье. Для x86 вообще почти все барьеры — noop. И только store/load требует барьера. Но! Мы видели у Саши Ланцова на графиках, что release/acquire быстрее sequentially consistent исполнения на x86. Как так? Всё просто: абстрактная модель с четырьмя такими барьерами не позволяет описать release/acquire! (Можете даже в исходники jdk заглянуть, они там отдельные)

В своё время (очень очень много лет назад) я увидел iriw и никак не мог понять, как с помощью этих барьеров его описать. Это меня очень мучало, я во сне даже это видел. Пришёл на JPoint. Пытался спросить г-на Шипилёва, но его всё время перехватывали, поэтому он меня отфутболил к г-ну Елизарову, который просто цензурно, но грубо послал меня на хер, с посылом, что дебилам это не нужно, отвали и забей, мальчик. ¯\_(ツ)_/¯
Но мальчики не сдаются. Я поймал г-на Шипилёва где-то во время какого-то доклада и он показал мне это. И это офигенно, почитайте на досуге.

Теперь давайте посмотрим, как устроены внутри setRelease и getAcquire, да и в целом все инструкции с барьерами внутри. Важный для понимания факт: при записи барьер выставляется ПЕРЕД самой записью, а при чтении — ПОСЛЕ самого чтения. Это может быть контринтуитивно. Но если подумать от гарантиях, то всё встанет на свои места. Смысл примерно такой:

Если мы увидели конкретную запись, то увидим и все предыдущие
Если мы прочитали какое-то значение, то его же должны видеть все последующие

Это неаккуратно, но передаёт мой посыл — куда думать.

Ну так вот. Для release/acquire на ppc нужны lwsync и до записи и после чтения. Для sequentially consistent нужна более тяжёлая артиллерия: [hw]sync на чтении. Для x86, как мы видели в cookbook'е, для sc нужен только mfence после чтения. А вот для release/acquire вообще ничего не нужно ни на чтении, ни на записи! Мы специально проверили, что opaque на x86 дает ту же корректность и ту же производительность, что и release/acquire. Напомню, что opaque ставит только компиляторные барьеры (не дает оптимизировать через компиляторный барьер). А всё благодаря TSO (total store order).
Интересный факт: явная инстркция барьера на x86 работает (работала?) медленнее, чем дающая те же гарантии атомарная инструкция lock addl, поэтому в jdk используется (использовалась?) именно последняя.

Я уже не знаю, зачем существует этот пост, но не могу остановиться.
КОРОЧЕ. В С/С++11 есть еще семантика release/consume... Она еще чуть слабее release/acquire и нужна вот зачем. Вы можете прочитать с consume записанную с release переменную-указатель и вам гарантируется, что по этому указателю вы увидите данные записанные до release записи. Т.е. зависимость по данным порождает видимость. НО! Эта штука была нужна, на сколько я знаю, только на альфах, которые канули в лету. Так что забейте.

Have a nice day, как говорится.

И, пожалуйста, не пишите на основе этой статьи компиляторы! Я не выверял формулировки, мог быть не точен, а мог и вовсе ошибиться.

Ну чёт даже не знаю

Как я "золото" нашёл

Одним летом, когда мне было лет 12 - 14, я приехал на дачу к бабушке. Свободного времени было выше крыши, поэтому бо́льшую его часть я разъезжал по деревне на велосипеде. Сначала объездил все асфальтированные дороги, потом всё побережье реки, потом грунтовки и тропинки. В конце концов я начал ездить просто по лугу, на котором иногда паслись козы и бараны, но по большей части на нём не происходило ничего.

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

Родители, конечно, сильно удивились, что сын притащил откуда-то самородок. Но мой энтузиазм разделил только отчим. Я отдал ему этот булыжник, чтобы он свозил его в лабораторию, на анализ состава.

Только пару месяцев томительного ожидания спустя мне удалось узнать у отчима, что же там с этим самородком. Это была медь. Разочарование.

До сих пор ума не приложу, откуда посреди поля взялся кусок руды. Скорее всего, кто-то очень сильный нашёл при вспашке огорода (в той деревне много привозной земли) и вышвырнул его подальше. А привезти могли откуда угодно: в Башкирии есть промышленная добыча как меди, так и золота.

А самородок тот я так больше никогда и не увидел.

Мысли в слух

Я опять давно ничего не писал, поэтому вот вам поток сознания.

Попробовал тут этот ваш ChatGPT для работы. Что ж, очень неплохо пишет sql запросы, помогает в пятницу вечером провалидировать рефакторинг, если вы вдруг почему-то не написали тесты, которых по какой-то неведомой причине не было и до вашего вмешательства.
Но чтобы прям вот тикеты решать... По-моему пока ИИ до этого не дошёл. Всё-таки самая сложная часть по-прежнему: перевести из "хочу Х" в "надо переделать Y, чтобы он был Z", с учётом кучи ограничений: не уронить надёжность, перфоманс, читаемость, поддерживаемость; сделать легко отключаемым по рубильнику, легко расширяемым (но только там, где надо!), обратно совместимым; уложиться в код стиль, дизайн стиль, архитектуру приложения. Но это ладно, могу в теории представить огромный сложный промпт с этим всем. А вот сказать, что как просили, сделать нельзя, зато можно вот так и так; согласовать такое; синхронизироваться с соседями по api и срокам разработки; синхронизировать выкатки, найти способ проверить в условиях ограниченных прав доступа и неработающих кусков тестового окружения; попинать того чувака, который всё ещё не ответил, эскалировать в его руководителя — это всё че-то пока кажется сложным.
Особо умные уже подумали: так зачем это все нужно, если можно просто убрать людей из цепочки? А вот людей сложно убрать. Кто должен писать промпты, кто-то должен валидировать выхлоп. Целиком большую задачу LLM пока не может прожевать, по моему опыту (да и проверить никто не сможет), а если разбить на куски, то нужна синхронизация, а учитывая то, как часто модели выдумывают, ошибаются и откровенно врут, я не знаю, как они будут договариваться, ведь у них пока что garbage in -> garbage out, булшит фильтра в голове, как у человека, у них пока нет.

Ну или я не прав, переубедите в комментариях.

Для тех, кто приходит за чем-то полезным, у меня есть заготовка
Шикарное видео про феминитивы, с позицией, которую я разделяю
Наконец-то всё разъяснили настоящие филологи, а не троечник (ладно, у меня был хор по лингвистике, но откровенно слабенький)
https://youtu.be/7eC2GNCVDH8

Снова про ретроспективы

Основная мысль: нужно регулярно менять формат.

Подробнее. Я уже писал про наши ретро, ориентированные на каждого сотрудника в отдельности. Мы там крутили формулировки, фреймили, это помогло на время. Но дальше мы просто изменили формат радикально и стали проводить ретро в разрезе команды.
Раньше вопросы были про "что помешало [тебе] успеть", "что могло бы помочь [тебе]", "что нового узнал [ты] “. Хотя черно указания числа в вопросах нет, они фреймятся в юнит, в тебя.
Теперь вопросы стали про "что нам прекратить делать", "что начать", "что продолжить". Переключение сразу вытащило на свет кучу топиков. Сразу стало что обсудить.

Недавно я наконец почувствовал, что у нас начинается фаза storming. Есть мнение, что модель Такмана бесполезна, но я пока не уверен в этом. Так вот, мы поймали, как мне кажется, идеальный момент для ретроспективы в формате that guy, this guy. Обозначили границы, дали анонимную обратную связь друг другу, кое-где это помогло разанонимизироваться, потому что договорились и "помирились". Срезали сильно демотивирующие моменты, вызванные банально разным пониманием.
Команда очень довольна новым форматом. Опять 😊

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

Весна

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

Но эта весна была другой. Я с удивлением обнаружил, что мне понравилось. В феврале в Белграде было серо и уныло. И много собачьих какашек на улице (как весной в России, только хуже!).
Но вот к середине марта/апрелю стало замечательно. Во-первых, солнце. Очень тепло. Во-вторых, сразу всё цветёт, всё зелёное, фиолетовое, красное, синее, розовое — очки красиво. Приятно погулять (чего не скажешь о привычной мне весне).

Теперь я видел красивую и приятную весну. Мне понравилось. Делаю вывод, что мне надо жить где-то не в Москве всё-таки.

Про результаты некоторых моих менеджерских потуг

Писал про то, что люди не общаются. Очень круто сработали кофейные встречи по средам, но нужно было раскручивать людей на то, чтобы узнали друг друга (см. мой тейк про тамаду в том посте). Мы к ним добавили зум пиво по пятницам с кулсториями на пару часов (я такое могу, да) и стало ещё лучше.

Парное программирование это просто находка (внезапно). Во-первых, сплочает команду. Во-вторых, онбординг теперь проходит в среднем в три раза быстрее, чем до внедрения этих сессий. В-третьих, ребята за этот несчастный час зачастую вытаскивают ощутимого размера тикеты! Добавляем сюда сразу сокращение времени ревью, потому что вместе делали и повышение качества, потому что две головы лучше. Получаем отличную вещь. Сейчас пробуем внедрять больше таких встреч.

Любопытную идею мне подкинул мой товарищ, один из С- в райфе (там их много, не возбуждаетесь). Можно просто включить зум и скинуть в чат команды — заходите, кто хочет поработать вместе. С одним из сотрудников совершенно случайно получилось такое попробовать несколько раз. Опять же, субъективно очень продуктивно: тут тебе и резиновая уточка, и умный собеседник, и обучение друг у друга, и тимбилдинг со смехуёчками. Рекомендую, короче. Но сложно, если у вас всё в митингах, да.

Кстати, про bus factor. Мы свою единичку пробили (ушёл от нас старожил). Но на удивление спокойно прошло. Мы сильно потеряли в производительности, как команда, но сакральные знания нас почти не тормозят. Здесь, конечно, заслуга и всех доков, и борьбы за оформление тикетов, но бо‌льшую часть лично я атрибутирую к парному программированию.

ДПДГ

Я как-то незаслуженно мимолётно упомянул об этом методе в посте про то, как я чуть не умер. Исправляю это недоразумение.

Метод позволяет справиться с ПТСР, некоторыми паническими атаками и некоторыми страхами. Я пробовал использовать только при втором.

Десенсибилизация и переработка движением глаз — это один из немногих доказано работающих (если ссылки на статьи не сгенерировала нейросеть, конечно) методов. В 2019 году в Nature даже публиковали статью, описывающую механизм работы этого метода, но я не читал.

Вообще рекомендуется делать практику с терапевтом. И практика эта в целом труднее, чем кажется. Но можно делать и самому.

В чём суть?
Нужно сконцентрироваться на травмирующем воспоминании (вспомнить и сидеть переживать его заново). Одновременно с этим надо медленно водить глазами. Можно влево-вправо, можно вверх-вниз, можно описывать окружность, бесконечность, геометрические фигуры. Я смотрю вот это видео и слежу за шариком.
Полезно фиксировать уровень тревоги во время воспоминания, по шкале от 0 до 10. Прекращать можно, когда уровень тревоги упал до 0-1. Это обычно несколько минут (я в 10 укладываюсь всегда). Всё. Вот так просто.

Википедия пишет, что три сеанса обычно хватает для проработки события уровня автомобильной аварии. Мне один сеанс помог с эпизодом гипертонического криза. Два сеанса с ТЭЛА и всей реанимацией. *У меня были панические атаки, особенно жесткая была в аппарате МРТ. Что любопытно, окружающие никогда не понимают, что я в ужасе.

А узнал я об этом методе от психологов, которых привлекал Райф (они были профессионалы по ПТСР), когда ковид согнал нас всех на удалёнку. Видать, с таким стрессом тоже помогает справиться.

Очень интересная небольшая серия постов в канале у Бориса. Речь о распределениях экстремальных величин (максимумов и минимумов). Идеи из этой области иногда применяют в оценках realized волатильности, но контекстов множество. Борис как раз рассматривает максимальную продолжительность жизни человека.
https://t.iss.one/BorisBurkov/686