#пятничная_картинка

Не то что я хорошо умею компьютеры...
Просто плохо умею сдаваться

Семейные проблемы и эпистемическая теория игр

История со скриншота:

➡️ Рассказал матери Кое-Что-Серьезное и попросил не говорить отцу. Она рассказала отцу и попросила не говорить мне. Отец позвонил мне, сказал, что знает, и попросил не говорить матери.

➡️ Теперь мы все всё знаем, но поговорить не можем.

Эта история красиво иллюстрирует определение "общего знания" (common knowledge). "Красиво" -- потому что показывает существенность требования знания о чужих знаниях (третья часть определения).

Рассказываю подробнее.

Общее знание -- это ситуация, когда
1. Все участники какой-то группы знают о некотором факте
2. Все знают, что все другие знают о факте
3. Все знают, что все знают, что все осведомлены о факте
4. И так далее до бесконечностм

Если неформально, то общее знание — это что-то, известное всем настолько, что ни у кого никакой мысли возникнуть не может, что кто-то этого не знает или не знает, что это общеизвестно.

А теперь обратно к формальному.

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

Пример, когда выполняется пункт 1, но не пункт 2, простой:
В семье умерла кошка (=Кое-Что-Серьезное).
Сын, мать и отец по очереди независимо друга от друга увидели мертвое тело.
Каждый знает о Факте (пункт 1 выполняется), но не знает, что другие знают (пункт 2 не выполняется).

А теперь смотрим на историю на картинке:
* все знают о Серьезном Факте — пункт 1 выполняется
* каждый знает, что все другие знают: сын сам сказал матери и получил звонок от отца, мать услышала новость от сына и сказала отцу, отец узнал Серьезный Факт от матери и говорил о нем с сыном — пункт 2 выполняется
* но не все знают, что все знают, что все знают о Серьезном Факте: мать не знает, что сын знает, что отец знает о Факте. Пункт 3 не выполняется. Серьезный Факт не является общим знанием.

Вот такая история.

А что получится, если теперь сын позвонит матери и скажет "мне звонил отец и сказал, что ты ему рассказала"?

Что такое "клёвый проект, в котором здорово работать"?

Для меня это что-то вроде "проект, в пользу которого верю" + "хороший климат в команде" + "есть простор для экспериментов".

Дорогие читатели, а что такое "классный проект" для вас?

И (неисчерпывающий) список для вдохновения:

1.1) Большой проект
1.2) Надежный проект, никуда не денется в ближайшие 15 лет
1.3) Известная компания
1.4) Платят много денег
2.1) Делают сервис, которым пользуются очень много людей
2.2) Делают сервис, который менят жизнь к лучшему
2.2) Делают сервис, который приносит много денег
2.3) Делают сервис, которым пользуюсь я
2.4) Делают сервис, которым пользуются мои знакомые
2.5) Смогу хвастаться: смотрите, вот эту штуку сделал я
2.6) Просто интересная предметная область
3.1) Хорошо налажена постановка задач
3.2) Хорошо налажено тестирование
3.3) Хорошо налажено обеспечение бесперебойной работы сервиса
3.4) Хорошо налажено документирование
3.5) Работают по Scrum
4.1) У проекта большие данные
4.2) У проекта большая нагрузка
4.3) Используют микросервисную архитектуру
4.4) Используют Rust
4.5) Нет легаси
5.1) Буду программировать хитрые алгоритмические штуки
5.2) Буду программировать хитрую асинхронщину и распределенные хэш-таблицы
5.3) Буду программировать и больше ничем не заниматься
6.1) Свободный график
6.2) Строго нормированный рабочий день
6.3) Будут коллеги, у которых много чему смогу научиться
6.4) Сплоченная команда
6.5) Не надо ни с кем общаться
7.1) Круто изучу реляционные базы данных
7.2) Научусь делать высокопроизводительные сервисы
7.3) Научусь хитрым алгоритмическим штучкам
7.4) Научусь хитрой асинхронщине и распределенным хэш-таблицам
7.5) Научусь тестированию
7.6) Научусь эксплуатации сервисов
7.7) Научусь управлению проектами
7.7) Изучу весь проект и стану ведущим разработчиком
7.8) Ничему не надо будет учиться, мои знания идеально подойдут
8.1) Смогу реализовывать свои идеи
8.2) Смогу выбирать, какие задачи делать
8.3) Смогу выбирать, в какой команде работать
8.4) Буду выступать на конференциях

🧑‍💻🚀💰📊📆

#пятничная_картинка

Кстати, конвейерная лента с полуоборотом была когда-то запатентована.

Вот здесь обсуждают, насколько это полезная конструкция: https://skeptics.stackexchange.com/questions/12260/do-möbius-strip-conveyor-belts-last-longer

(Коротко: современные материалы сделали ненужным трюк с перекручиванием)

#пятничная_картинка

Второй кадр: добро пожаловать в секретный интернет роботов

Третий кадр: Ранее: Докажите, что вы человек

Как я собирала zsh с помощью ChatGPT
Спойлер: 1. Собрала. 2. ChatGPT умничка, но не на все сто.

Захотела я собрать zsh из исходников. Причем не как-нибудь, а в статический бинарник.

Для контекста: слова configure, make, build, install я конечно понимаю, но сборкой ПО из исходников обычно не занимаюсь и могу не знать даже очень широко распространенных соглашений вокруг инструментов сборки.

Собрать динамически линкуемый бинарник — легко: ./configure && make, это написано в инструкции в исходном коде.

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

Идти и внимательно разбираться не хочется, хочется как-нибудь побыстрее. В духе времени решила спросить ChatGPT: How do I build a static executable of zsh in Ubuntu?

Запрос отправляла в две версии: 3.5 и 4.0
Обе сделали вид, что поняли мою задачу и выдали аккуратно структурированные инструкции. Дальше начались особенности.

ChatGPT 3.5 написала инструкцию для zsh 5.8 (было видно по имени архива в инструкции), и для 5.9 она не давала нужного эффекта: сборка проходила успешно, но file на получившийся бинарник говорил dynamically linked.

ChatGPT 4.0 не привязывалась к версии zsh. Она советовала установить две переменные: LDFLAGS='-static' LDSTATIC='-static'. Одна маленькая проблема — переменные предлагалось внести в файл, которого в исходном коде не было.

Copy-paste не получился, пришлось еще почитать инструкцию по сборке, конфиги и код.

Быстро нашлось, что ./configure --help упоминает переменную LDFLAGS, а дальше естественно напрашивалось LDSTATIC отправить туда же.

Итого получилось: ./configure LDFLAGS='-static' LDSTATIC='-static' && make, и ура, бинарник собрался и file Src/zsh сказал statically linked.

На все — от поиска "официального релиза исходников" до результата — ушло 30 минут.

Наблюдения про ChatGPT:
* время она мне явно сэкономила
* инструкции от обеих версий выглядели очень хорошо: саммари "что собираемся сделать", аккуратные пункты, команды "копируй-вставляй"
* прямолинейно применить ни одну инструкцию от ChatGPT не получилось
* ChatGPT 4.0 помогла больше, чем 3.5

В любом случае, спасибо технологиям. И теперь у меня есть статический бинарник zsh 😊

Во время встречи работа фасилитатора -- чтобы каждый был услышан.

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

Оба обсуждения вернула на правильные рельсы. В одном случае хватило мягкого напоминания о целях, в другом мягкого не хватило.

#будни_фасилитатора

#будни_фасилитатора и немного #command_line_magic

Готовлю встречу для хобби-проекта.

Намерение -- обсудить набор слайдов к презентации: какие противоречия в них видим, что и как можно улучшить. Участники — 4-7 человек, время — 30-60 минут. Презентация — 30+ кадров в pptx. В результате обсуждения надеемся получить приоритизированный список идей к улучшению.

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

Делаю:
🔹 открываю слайды в LibreOffice, экспортирую в pdf
🔹конвертирую pdf в серию картинок с помощью ImageMagick: convert slides.pdf slides.jpg
🔹 полученную гору картинок drag-n-drop-ом тащу в Miro
🔹 выделяю картинки в Miro, добавляю средне-серую обводку
🔹 через align objects / distribute horizontally распределяю кадры

Основной материал, вокруг которого буду выстраивать встречу — готов. Иду сочинять прогревочные и основные вопросы и делать прочие визуальные заготовкии в Miro 🗒🖊

#пятничная_картинка

Второй кадр: Вы робот? Напишите ответ здесь.

Третий кадр: Это деление несущественно.

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

Между прочим, каналу -- год 🎂

Спасибище всем, кто читает, ставит реакции, комментирует. С вами гораздо лучше, чем без вас.

Как думаете, о чем стоит больше писать дальше? Отмечайте реакциями, пишите комментариями!

💯 про математику
🧑‍💻 про техническое
🤝 про управленческое
✍️ про фасилитацию
🔥 про что угодно

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

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

🧑‍💻🧑‍💻🧑‍💻
"Найти курсы" -- это выглядит уже решением, а проблема внутри какая-то другая.

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

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

И что делать?

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

Но если дотошного анализа проблемы еще не было -- я бы вложилась в анализ. Сначала в одиночку, потом с командой/заинтересованными лицами.
По формату начала бы с факторов, которые участвуют в ситуации, и как они друг на друга влияют.
🧑‍💻🧑‍💻🧑‍💻

Про использование MySQL в Яндекс.Директе: https://youtu.be/x03CwcLLDW4

А это мой давний доклад на Я.Субботнике про БД.

Рассказ 2017 года, но там уже десятки шардов и десятки терабайт данных; а клёвые инструменты в Директе были вообще всегда.

Три части в рассказе:
🔹Шардинг
🔹DDL на больших и гигантских таблицах
🔹 История обновления данных на основе обработки бинлогов

Противоречие обучения: незнание ступенчато, а узнавание постепенно.

Когда сравниваешь неумеющего себя с умеющим кем-нибудь — видишь разрыв, большую ступеньку: "вот это он умеет, а я нет".

Легко начать мечтать "вот буду учиться, научусь и перепрыгну этот разрыв".

Когда сравниваешь учащегося себя сегодняшнего с собой вчерашним — часто видишь не ступеньку, а маленький кусочек плавного прогресса: "вроде ничего такого не умею сегодня, чего не умел вчера, ну разве что спотыкаюсь меньше". Может быть даже и этого не видишь, а только "не получается, не получается, не получается".

Результат? Перепрыгивания, о котором мечталось, не происходит и не происходит. Мечта "научусь" не сбывается. Грустно!

(Вообще-то не просто грустно, а надо менять этот паттерн. Но про это в другой раз)

Разные перспективы

Верхний кадр:
Изучаю новый фреймворк
Ты можешь, ты уже делал это

Нижний кадр:
Смотрю, как кто-то другой изучает фреймворк, который я знаю.
Сюда / Ну давай уже

И этот комикс тоже о том же противоречии обучения: смотришь вперед -- надо преодолевать большое и страшное незнание. Смотришь назад -- вроде ничего такого и не сделал

Припозднившаяся #пятничная_картинка

Отметьте все картинки, где есть человеки.

Про шестерых я знаю, кто они; про троих -- нет ((

SaintTeamLeadConf -- съездила на конференцию

Записала недодюжину коротеньких находок.

Интересно, можно по ним угадать, на какие секции я ходила? ))
Программа здесь, если что: https://teamleadconf.ru/spb/2023/schedule

1🔹 Новое применение ценностям.
Если выбирать, чтобы убежать от нежелательного -- об этом выборе потом часто жалеют. Если выбирать из ценностей -- это выбор, который потом воспринимается хорошо.

2🔹 Если какая-то мысль захватывает, не отпускает и не дает больше ни на что посмотреть. Упражнение.
Включить мысль во все более и более широкий контекст. Произносить отчетливо вслух или про себя:
* "какие же смежники упыри"
* "я думаю, что смежники большие упыри"
* "я замечаю, что я думаю, что смежники большие упыри"
* "это интересно, что я могу заметить, что я думаю, что смежники..."
* "могу рассказать, как интересно, что я могу заметить, что я думаю..."
На каждом шаге обращать внимание на свои ощущения. На 2-3-4 итерации обычно отпускает.

3🔹 Ткнуть пальцем в проблему часто важнее-полезнее, чем помогать с решением.

4🔹 Говорят, что люди узнают, что происходит, по эмоциям, которые испытывают. Не "просходит страшное, поэтому боюсь", а "боюсь, и из этого понимаю, что происходит страшное".

5🔹 Частенько проблемы "здесь в моменте" показывают на систематические изъяны: нет ретроспектив, нет ясных целей, нет общепринятых правил, сломана коммуникация... Но (некоторые? многие?) тимлиды в аудитории все равно хотят лекарство в моменте.

6🔹 Полезная замена: вместо "Я не могу на это повлиять" говорить "Мне сложно на это повлиять, потому что ..."

7🔹 Видеоблог надо заводить за два года до того, как он понадобится.

8🔹 Если выходишь на сцену и видишь мрачные лица в аудитории.
Это не потому, что ты — лох, а потому что слушатели живут здесь.

9🔹 Формула изменений с удовольствием:
* прошлое, на которое можно опереться
* неидеальное, но приличное настоящее
* ясный и завлекательный образ будущего
* убрать риск облажаться публично
* побольше привычных мест, людей и действий

10🔹 Фрирайтинг и сторителлинг усиливают эмоции, лейбеллинг приглушает.

11🔹 Самые популярные советы, которые люди дают себе после дистального моделирования (из позиции кого-то другого): (1) просто делай уже; (2) забей и не делай.

А в тетрадочке еще под сотню страниц подробных записей. В общем, интересно 👍

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

Если по порядку, то так:
🔹 составить, опубликовать и посмотреть схему сложного сервиса — непростое занятие, с инструментами не все гладко
🔹 во всех сервисах, где я работала, я постоянно рисовала какие-нибудь схемы и постоянно думала, как это делать лучше
🔹 с год назад я собрала все материалы и мысли, какие были, и синтезировала идею: какой новый инструмент надо бы разработать, чтобы стало лучше
🔹 но перспективы разработать такой инструмент были не очень — ресурсов разработки видно не было
🔹 а потом один за другим у нас в отделе оказались два студента-дипломника, которые хотели делать дипломы на рабочих задачах
🔹 и тут мы согласовали этот самый сервис схем как парт-тайм экспериментальный проект, на котором коллеги сделали бы дипломы
🔹весь прошедший учебный год я понемногу прорабатывала юзер-стори, декомпозировала функциональность, приоритизировала, а коллеги-дипломники программировали, дебажили, конфигурировали и деплоили
🔹и вот в только что закончившемся июне оба защитились
🔹 а у нас в отделе появился новый клёвый сервис-инструмент
🔹 ура ))

История с "делать схемы сервисов" — важная для меня, я хотела бы писать об этом больше.

А на картинке — USM, по которой работали этот год

#пятничная_картинка

👾 -- понимаю, что тут происходит
👀 -- не понимаю
👍 -- неважно что происходит, поддерживаю картиночки

Архитектура инцидента

Рассказ — следующим сообщением

Архитектура инцидента

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

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

Итак, инцидент.

Участвуют несколько постоянно работающих сервисов и одна регулярная процедура сверки.

Взаимодействие между сервисами-участниками идет так (номера соответствуют схеме):

1. Пользователь выполняет действие в веб-интерфейсе. Этот запрос попадает в Сервис #1

2. Сервис #1 по некоторой логике определяет, в какой из сервисов-бэкендов следует отправить запрос

3. Сервис #1 отправляет запрос на обработку в выбранный бэкенд

4. Параллельно в природе появляется лог "такой-то пользовательский запрос подлежит обработке таким-то бэкендом".
Кто именно генерирует этот лог -- внезапно не вполне ясно. То ли сам Сервис #1 пишет, то ли какая-то прокси перед ним

5. Лог из п.4 проходит через несколько сервисов: #2, #3, #4, #5

6. Время от времени запускается сверка: какие запросы распределялись по бэкендам по данным самим бэкендов и по данным, накопленным в сервисе #5

7. Если сверка находит расхождения — разбираются все-все-все, в том числе и наш сервис #3

Так как какое-то время лог в п.4 был неправильный — предвидим при очередной сверке расхождения, которые будут объясняться этой проблемой с логом.

Чем мне нравится схема?

На схеме легче обнаруживаются неясные места:
- Действительно ли проблема была только в записи лога, или в выборе бэкенда тоже? Как это узнать?
- Каков все-таки механизм генерации лога? Насколько этот механизм подвержен поломкам?
- Можно ли сверять лог и данные бэкендов непосредственно, без цепочки сервисов #2-#5?
- А как проверяется и мониторится, что выбор сервиса-бэкенда делается правильно, без систематических ошибок?

На схеме можно поместить десяток объектов и связи между ними, и разумно рассуждать обо всех них. Без схемы это (1) трудно даже в одиночку; (2) а если внесколькером — никогда не понятно, одинаковая ли картинка сложилась в головах у разных людей.

Составляйте схемы инцидентов, если еще не!

#в_продакшене_только_и_разговоров_что_об_инцидентах