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

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

Вот здесь обсуждают, насколько это полезная конструкция: 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) а если внесколькером — никогда не понятно, одинаковая ли картинка сложилась в головах у разных людей.

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

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

Из точки A в точку B, ч.1

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

Делюсь первой дельтой:

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

2. Три года назад я этого не делала. У меня были практики про встречи и про записи, но другие, и выхлоп от них был совсем другой.

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

TLDR: "Слушать, электронно записывать и осмыслять одновременно" -- это удобно-полезно, мне нравится; и начала это делать я совсем недавно

Инструменты и процессы -- как вантовые оттяжки

1. Должны поддерживать
и
2. Чтобы выполнять свою функцию, должны создавать напряжение

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

Отметьте все квадраты, в которых есть баги