Асимметрия везения и невезения, квази-цитата
Года полтора назад прочитала примерно такое про везение и невезение:
▶️
(В проектах по разработке программного обеспечения) счастливые и несчастливые случайности вполне могут просходить с одинаковой частотой.
Но! Есть разница в том, как они действуют.
Несчастливая случайность срабатывает сама по себе, "не заметить" ее не получится. А удачную случайность еще надо заметить и суметь воспользоваться. Возможно, для этого нужна предварительная подготовка. Итог: везение можно не заметить, не использовать.
Пример: я хочу в субботу как можно раньше приехать из Москвы в Петушки. Я знаю, что первая электричка уходит в 6:17 и прибывает в 9:04. Происходит удачное: в субботу назначают дополнительную электричку в 4:36. Если я заранее посмотрю расписание, замечу новую электричку и успею на вокзал -- в 7:16 я буду уже в Петушках, и скажу "повезло". Но я могу не посмотреть, не заметить или не успеть, и везение пройдет мимо.
В разработке аналогично. Заказчик подумает, что часть фич не нужна; соседний проект отложат и освободится еще одна команда; в команде найдется классный эксперт как раз в нужной области. Если это заметить, быть готовым, и использовать, то проекту повезло. Если не замечать, не быть готовым, не использовать -- в проекте будут только несчастливые случайности.
⏹
И про источник. Я была довольнь сильно уверена, что прочитала такое в книге "Time Predictions: Understanding and Avoiding Unrealism in Project Planning and Everyday Life", авторы Torleif Halkjelsvik, Magne Jørgensen. Но цитату сейчас найти не могу :( Так что может быть и не эта книга, а пост в каком-нибудь блоге
Года полтора назад прочитала примерно такое про везение и невезение:
▶️
(В проектах по разработке программного обеспечения) счастливые и несчастливые случайности вполне могут просходить с одинаковой частотой.
Но! Есть разница в том, как они действуют.
Несчастливая случайность срабатывает сама по себе, "не заметить" ее не получится. А удачную случайность еще надо заметить и суметь воспользоваться. Возможно, для этого нужна предварительная подготовка. Итог: везение можно не заметить, не использовать.
Пример: я хочу в субботу как можно раньше приехать из Москвы в Петушки. Я знаю, что первая электричка уходит в 6:17 и прибывает в 9:04. Происходит удачное: в субботу назначают дополнительную электричку в 4:36. Если я заранее посмотрю расписание, замечу новую электричку и успею на вокзал -- в 7:16 я буду уже в Петушках, и скажу "повезло". Но я могу не посмотреть, не заметить или не успеть, и везение пройдет мимо.
В разработке аналогично. Заказчик подумает, что часть фич не нужна; соседний проект отложат и освободится еще одна команда; в команде найдется классный эксперт как раз в нужной области. Если это заметить, быть готовым, и использовать, то проекту повезло. Если не замечать, не быть готовым, не использовать -- в проекте будут только несчастливые случайности.
⏹
И про источник. Я была довольнь сильно уверена, что прочитала такое в книге "Time Predictions: Understanding and Avoiding Unrealism in Project Planning and Everyday Life", авторы Torleif Halkjelsvik, Magne Jørgensen. Но цитату сейчас найти не могу :( Так что может быть и не эта книга, а пост в каком-нибудь блоге
👍4🔥1👏1
Тикеты от людей и алерты от машин -- одно и то же или разное?
На днях столкнулась с вопросом: (в проекте по разработке и поддержке веб-сервиса) разбирать жалобы от пользователей и разбирать срабатывания автоматических алертов в продакшене -- это одна и та же работа или разные?
Казалось бы, и то и другое -- сигнал о проблеме в сервисе; какая разница, каков источник сигнала?
Тем не менее, мне кажется, что это разные работы, хотя развернутые аргументы привести пока не готова.
А еще тут есть второй этаж: а почему собственно полезно ответить на этот вопрос?
-- Для оптимизации усилий. Если работы разные -- возможно, их надо выполнять разными специалистами. По крайней мере, не смешивать оба вида работ в одних руках в одно время. Если работы разные -- у одного человека могут быть в них разные квалификации. Может быть, это снова ведет к разделению ответственности между разными специалистами. И наверняка разным работам требуется разное обучение.
Если все это аккуратно учесть, то напрягаться можно будет поменьше, а результаты получать побольше
На днях столкнулась с вопросом: (в проекте по разработке и поддержке веб-сервиса) разбирать жалобы от пользователей и разбирать срабатывания автоматических алертов в продакшене -- это одна и та же работа или разные?
Казалось бы, и то и другое -- сигнал о проблеме в сервисе; какая разница, каков источник сигнала?
Тем не менее, мне кажется, что это разные работы, хотя развернутые аргументы привести пока не готова.
А еще тут есть второй этаж: а почему собственно полезно ответить на этот вопрос?
-- Для оптимизации усилий. Если работы разные -- возможно, их надо выполнять разными специалистами. По крайней мере, не смешивать оба вида работ в одних руках в одно время. Если работы разные -- у одного человека могут быть в них разные квалификации. Может быть, это снова ведет к разделению ответственности между разными специалистами. И наверняка разным работам требуется разное обучение.
Если все это аккуратно учесть, то напрягаться можно будет поменьше, а результаты получать побольше
🤔1
Тикеты от людей и алерты от машин...
Anonymous Poll
7%
Одно и то же
87%
Разное
7%
Все сложнее, напишу комментарий
0%
Хочу посмотреть результаты
Расскажу-покажу парадокс Симпсона
#статистика
Контекст: пытаемся статистически проверить влияние лекарства/процедуры/технологии/<чего-то еще>.
В симпсоновски-парадоксальном случае может показаться, что для каждой подгруппы проверяемое средство делает хуже, а для всей группы в целом — лучше.
Левшам хуже, правшам хуже, а всей группе целиком -- лучше 🤯
Спойлер:в действительности симпсоновски-парадоксальные результаты означают, что эксперимент выполнен некорректно.
Пример!
В офис завезли новый кофе. Производители заявляют, что от этого кофе разработчики делают меньше багов. Хотим проверить.
Берем две группы: экспериментальную, которая пьет новый кофе, и контрольную, которая пьет кофе старый. Каждая группа состоит и джуниоров и сеньоров. Каждый разработчик выполняет одну задачу, и мы считаем, сколько задач выполнено с багами, а сколько без.
В контрольной группе 90 джуниоров, которые сделали 45 багов (50%) и 10 сеньоров, которые сделали 1 баг (10%). Общий процент баговых реализаций — (45+1)/100 = 46%
В экспериментальной группе 10 джуниров, которые сделали 6 багов (60%) и 90 сеньоров, которые сделали 10 багов (11%). Общий процент баговых реализаций — (6+10)/100 = 16%.
Если посмотреть на всех вместе, то багов стало в 3 раза меньше: 46% -> 16%. При этом и у джуниоров, и у сеньоров по отдельности багов стало больше: 50% -> 60%, 10%->11%.
Джуниорам хуже, сеньорам хуже, а группе целиком -- лучше 🤯
Числа как будто парадоксальные, но понятно откуда они такие: все стали делать багов больше, но у сеньоров багов все-таки сильно меньше, чем у джуниоров, и улучшение суммарного показателя видим из-за большей доли сеньоров в экспериментальной группе.
Почему так получилось? Похоже, разработчиков распределяли по контрольной и экспериментальной группам неслучайным образом. И да, это некорректный эксперимент, выводов из сравнения контрольной и экспериментальной групп делать нельзя.
Если мы можем сказать разработчику, какой кофе ему пить, то лучше бы взять всех участников и распределить по контрольной и экспериментальной группам честным рандомом.
А если не можем... Это еще другая история.
Нельзя просто так делить одни числа на другие и называть это статистической проверкой ))
#статистика
Контекст: пытаемся статистически проверить влияние лекарства/процедуры/технологии/<чего-то еще>.
В симпсоновски-парадоксальном случае может показаться, что для каждой подгруппы проверяемое средство делает хуже, а для всей группы в целом — лучше.
Левшам хуже, правшам хуже, а всей группе целиком -- лучше 🤯
Спойлер:
Пример!
В офис завезли новый кофе. Производители заявляют, что от этого кофе разработчики делают меньше багов. Хотим проверить.
Берем две группы: экспериментальную, которая пьет новый кофе, и контрольную, которая пьет кофе старый. Каждая группа состоит и джуниоров и сеньоров. Каждый разработчик выполняет одну задачу, и мы считаем, сколько задач выполнено с багами, а сколько без.
В контрольной группе 90 джуниоров, которые сделали 45 багов (50%) и 10 сеньоров, которые сделали 1 баг (10%). Общий процент баговых реализаций — (45+1)/100 = 46%
В экспериментальной группе 10 джуниров, которые сделали 6 багов (60%) и 90 сеньоров, которые сделали 10 багов (11%). Общий процент баговых реализаций — (6+10)/100 = 16%.
Если посмотреть на всех вместе, то багов стало в 3 раза меньше: 46% -> 16%. При этом и у джуниоров, и у сеньоров по отдельности багов стало больше: 50% -> 60%, 10%->11%.
Джуниорам хуже, сеньорам хуже, а группе целиком -- лучше 🤯
Числа как будто парадоксальные, но понятно откуда они такие: все стали делать багов больше, но у сеньоров багов все-таки сильно меньше, чем у джуниоров, и улучшение суммарного показателя видим из-за большей доли сеньоров в экспериментальной группе.
Почему так получилось? Похоже, разработчиков распределяли по контрольной и экспериментальной группам неслучайным образом. И да, это некорректный эксперимент, выводов из сравнения контрольной и экспериментальной групп делать нельзя.
Если мы можем сказать разработчику, какой кофе ему пить, то лучше бы взять всех участников и распределить по контрольной и экспериментальной группам честным рандомом.
А если не можем... Это еще другая история.
Нельзя просто так делить одни числа на другие и называть это статистической проверкой ))
👍3🔥1🤯1
Комманд-лайновые гаммы
#command_line_magic
Понадобилось мне тут "транспонировать" текстовую табличку.
Исходный файл такого вида:
Хочу получить такое:
В реальном файле полей было больше, несколько десятков, а значения — большие числа и числа со многими знаками после запятой.
Работа одноразовая, файл один, повторять не потребуется.
Кто как стал бы решать такую задачу? Приглашаю попробовать и может быть засечь время.
В следующем сообщении (https://news.1rj.ru/str/WritingOnStickyNotes/116) — пример данных, можно потестировать свои решения.
Мое решение — в комментариях
#command_line_magic
Понадобилось мне тут "транспонировать" текстовую табличку.
Исходный файл такого вида:
$ cat data.txtДве строки, в первой — названия полей через вертикальную черту, во второй — такое же количество значений (чисел), тоже через вертикальную черту.
aaa | bbb | ccc
1 | 2 | 3
Хочу получить такое:
aaa: 1Каждое поле — на отдельной строчке. Имя, двоеточие, пробел, значение. Порядок — такой же, как в исходном файле.
bbb: 2
ccc: 3
В реальном файле полей было больше, несколько десятков, а значения — большие числа и числа со многими знаками после запятой.
Работа одноразовая, файл один, повторять не потребуется.
Кто как стал бы решать такую задачу? Приглашаю попробовать и может быть засечь время.
В следующем сообщении (https://news.1rj.ru/str/WritingOnStickyNotes/116) — пример данных, можно потестировать свои решения.
Мое решение — в комментариях
Telegram
Мыслестикеры
Пример данных к прошлому посту (https://news.1rj.ru/str/WritingOnStickyNotes/115), можно потестировать свои решения.
И мой вариант преобразования — в комментариях там же
И мой вариант преобразования — в комментариях там же
🔥1🤔1
data.txt
2.3 KB
Пример данных к прошлому посту (https://news.1rj.ru/str/WritingOnStickyNotes/115), можно потестировать свои решения.
И мой вариант преобразования — в комментариях там же
И мой вариант преобразования — в комментариях там же
👍1🤯1
Семейные проблемы и эпистемическая теория игр
История со скриншота:
➡️ Рассказал матери Кое-Что-Серьезное и попросил не говорить отцу. Она рассказала отцу и попросила не говорить мне. Отец позвонил мне, сказал, что знает, и попросил не говорить матери.
➡️ Теперь мы все всё знаем, но поговорить не можем.
Эта история красиво иллюстрирует определение "общего знания" (common knowledge). "Красиво" -- потому что показывает существенность требования знания о чужих знаниях (третья часть определения).
Рассказываю подробнее.
Общее знание -- это ситуация, когда
1. Все участники какой-то группы знают о некотором факте
2. Все знают, что все другие знают о факте
3. Все знают, что все знают, что все осведомлены о факте
4. И так далее до бесконечностм
Если неформально, то общее знание — это что-то, известное всем настолько, что ни у кого никакой мысли возникнуть не может, что кто-то этого не знает или не знает, что это общеизвестно.
А теперь обратно к формальному.
Как обычно, если в определении несколько пунктов, интересно найти примеры, когда выполняется один, но не выполняется какой-то другой.
Пример, когда выполняется пункт 1, но не пункт 2, простой:
В семье умерла кошка (=Кое-Что-Серьезное).
Сын, мать и отец по очереди независимо друга от друга увидели мертвое тело.
Каждый знает о Факте (пункт 1 выполняется), но не знает, что другие знают (пункт 2 не выполняется).
А теперь смотрим на историю на картинке:
* все знают о Серьезном Факте — пункт 1 выполняется
* каждый знает, что все другие знают: сын сам сказал матери и получил звонок от отца, мать услышала новость от сына и сказала отцу, отец узнал Серьезный Факт от матери и говорил о нем с сыном — пункт 2 выполняется
* но не все знают, что все знают, что все знают о Серьезном Факте: мать не знает, что сын знает, что отец знает о Факте. Пункт 3 не выполняется. Серьезный Факт не является общим знанием.
Вот такая история.
А что получится, если теперь сын позвонит матери и скажет "мне звонил отец и сказал, что ты ему рассказала"?
История со скриншота:
➡️ Рассказал матери Кое-Что-Серьезное и попросил не говорить отцу. Она рассказала отцу и попросила не говорить мне. Отец позвонил мне, сказал, что знает, и попросил не говорить матери.
➡️ Теперь мы все всё знаем, но поговорить не можем.
Эта история красиво иллюстрирует определение "общего знания" (common knowledge). "Красиво" -- потому что показывает существенность требования знания о чужих знаниях (третья часть определения).
Рассказываю подробнее.
Общее знание -- это ситуация, когда
1. Все участники какой-то группы знают о некотором факте
2. Все знают, что все другие знают о факте
3. Все знают, что все знают, что все осведомлены о факте
4. И так далее до бесконечностм
Если неформально, то общее знание — это что-то, известное всем настолько, что ни у кого никакой мысли возникнуть не может, что кто-то этого не знает или не знает, что это общеизвестно.
А теперь обратно к формальному.
Как обычно, если в определении несколько пунктов, интересно найти примеры, когда выполняется один, но не выполняется какой-то другой.
Пример, когда выполняется пункт 1, но не пункт 2, простой:
В семье умерла кошка (=Кое-Что-Серьезное).
Сын, мать и отец по очереди независимо друга от друга увидели мертвое тело.
Каждый знает о Факте (пункт 1 выполняется), но не знает, что другие знают (пункт 2 не выполняется).
А теперь смотрим на историю на картинке:
* все знают о Серьезном Факте — пункт 1 выполняется
* каждый знает, что все другие знают: сын сам сказал матери и получил звонок от отца, мать услышала новость от сына и сказала отцу, отец узнал Серьезный Факт от матери и говорил о нем с сыном — пункт 2 выполняется
* но не все знают, что все знают, что все знают о Серьезном Факте: мать не знает, что сын знает, что отец знает о Факте. Пункт 3 не выполняется. Серьезный Факт не является общим знанием.
Вот такая история.
А что получится, если теперь сын позвонит матери и скажет "мне звонил отец и сказал, что ты ему рассказала"?
👍2🤯2⚡1🔥1
Что такое "клёвый проект, в котором здорово работать"?
Для меня это что-то вроде "проект, в пользу которого верю" + "хороший климат в команде" + "есть простор для экспериментов".
Дорогие читатели, а что такое "классный проект" для вас?
И (неисчерпывающий) список для вдохновения:
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) Буду выступать на конференциях
🧑💻🚀💰📊📆
Для меня это что-то вроде "проект, в пользу которого верю" + "хороший климат в команде" + "есть простор для экспериментов".
Дорогие читатели, а что такое "классный проект" для вас?
И (неисчерпывающий) список для вдохновения:
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) Буду выступать на конференциях
🧑💻🚀💰📊📆
👍3🔥1🤔1👌1
#пятничная_картинка
Кстати, конвейерная лента с полуоборотом была когда-то запатентована.
Вот здесь обсуждают, насколько это полезная конструкция: https://skeptics.stackexchange.com/questions/12260/do-möbius-strip-conveyor-belts-last-longer
(Коротко: современные материалы сделали ненужным трюк с перекручиванием)
Кстати, конвейерная лента с полуоборотом была когда-то запатентована.
Вот здесь обсуждают, насколько это полезная конструкция: https://skeptics.stackexchange.com/questions/12260/do-möbius-strip-conveyor-belts-last-longer
(Коротко: современные материалы сделали ненужным трюк с перекручиванием)
👍5🔥1🤩1
#пятничная_картинка
Второй кадр: добро пожаловать в секретный интернет роботов
Третий кадр: Ранее: Докажите, что вы человек
Второй кадр: добро пожаловать в секретный интернет роботов
Третий кадр: Ранее: Докажите, что вы человек
😁5🤯3🔥1
Как я собирала zsh с помощью ChatGPT
Спойлер:1. Собрала. 2. ChatGPT умничка, но не на все сто.
Захотела я собрать zsh из исходников. Причем не как-нибудь, а в статический бинарник.
Для контекста: слова
Собрать динамически линкуемый бинарник — легко:
А про статическую линковку непонятно. На github есть устрашающего размера скрипт тринадцатилетней давности, гугление дает неубедительно-разные советы про флаги, на стековерфлоу висит грустный неотвеченный вопрос. Выглядит так, что надо идти и внимательно разбираться в конфигурации сборки.
Идти и внимательно разбираться не хочется, хочется как-нибудь побыстрее. В духе времени решила спросить ChatGPT:
Обе сделали вид, что поняли мою задачу и выдали аккуратно структурированные инструкции. Дальше начались особенности.
ChatGPT 3.5 написала инструкцию для zsh 5.8 (было видно по имени архива в инструкции), и для 5.9 она не давала нужного эффекта: сборка проходила успешно, но
ChatGPT 4.0 не привязывалась к версии zsh. Она советовала установить две переменные:
Copy-paste не получился, пришлось еще почитать инструкцию по сборке, конфиги и код.
Быстро нашлось, что
Итого получилось:
На все — от поиска "официального релиза исходников" до результата — ушло 30 минут.
Наблюдения про ChatGPT:
* время она мне явно сэкономила
* инструкции от обеих версий выглядели очень хорошо: саммари "что собираемся сделать", аккуратные пункты, команды "копируй-вставляй"
* прямолинейно применить ни одну инструкцию от ChatGPT не получилось
* ChatGPT 4.0 помогла больше, чем 3.5
В любом случае, спасибо технологиям. И теперь у меня есть статический бинарник 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 😊
🔥5👍4❤2😁1😱1🏆1
Во время встречи работа фасилитатора -- чтобы каждый был услышан.
Сегодня на двух встречах складывалась ситуация: несколько участников начинали увлеченно обсуждать вопрос, а эксперты, ради мнения которых собирались встречи, не успевали и слова сказать.
Оба обсуждения вернула на правильные рельсы. В одном случае хватило мягкого напоминания о целях, в другом мягкого не хватило.
#будни_фасилитатора
Сегодня на двух встречах складывалась ситуация: несколько участников начинали увлеченно обсуждать вопрос, а эксперты, ради мнения которых собирались встречи, не успевали и слова сказать.
Оба обсуждения вернула на правильные рельсы. В одном случае хватило мягкого напоминания о целях, в другом мягкого не хватило.
#будни_фасилитатора
❤4🔥3👍2😁2
#будни_фасилитатора и немного #command_line_magic
Готовлю встречу для хобби-проекта.
Намерение -- обсудить набор слайдов к презентации: какие противоречия в них видим, что и как можно улучшить. Участники — 4-7 человек, время — 30-60 минут. Презентация — 30+ кадров в pptx. В результате обсуждения надеемся получить приоритизированный список идей к улучшению.
Хочу разобрать презентацию на отдельные слайды и положить в Miro, чтобы на встрече делать заметки поверх слайдов. Редактирование самих слайдов в Miro не требуется.
Делаю:
🔹 открываю слайды в LibreOffice, экспортирую в pdf
🔹конвертирую pdf в серию картинок с помощью ImageMagick:
🔹 выделяю картинки в Miro, добавляю средне-серую обводку
🔹 через align objects / distribute horizontally распределяю кадры
Основной материал, вокруг которого буду выстраивать встречу — готов. Иду сочинять прогревочные и основные вопросы и делать прочие визуальные заготовкии в Miro 🗒🖊
Готовлю встречу для хобби-проекта.
Намерение -- обсудить набор слайдов к презентации: какие противоречия в них видим, что и как можно улучшить. Участники — 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 🗒🖊
👍1🔥1🤔1👀1
#пятничная_картинка
Второй кадр: Вы робот? Напишите ответ здесь.
Третий кадр: Это деление несущественно.
Четвертый: Добро пожаловать в секретный интернет философов
--
любые проблемы с сайтом обусловлены фундаментальными ограниченями языка
Второй кадр: Вы робот? Напишите ответ здесь.
Третий кадр: Это деление несущественно.
Четвертый: Добро пожаловать в секретный интернет философов
--
любые проблемы с сайтом обусловлены фундаментальными ограниченями языка
👍3😁2👾2
Между прочим, каналу -- год 🎂
Спасибище всем, кто читает, ставит реакции, комментирует. С вами гораздо лучше, чем без вас.
Как думаете, о чем стоит больше писать дальше? Отмечайте реакциями, пишите комментариями!
💯 про математику
🧑💻 про техническое
🤝 про управленческое
✍️ про фасилитацию
🔥 про что угодно
Спасибище всем, кто читает, ставит реакции, комментирует. С вами гораздо лучше, чем без вас.
Как думаете, о чем стоит больше писать дальше? Отмечайте реакциями, пишите комментариями!
💯 про математику
🧑💻 про техническое
🤝 про управленческое
✍️ про фасилитацию
🔥 про что угодно
🔥14👨💻5💯4✍2🤝1
Какие курсы по базам данных посоветуешь?
-- спросили тут меня.
Контекст -- коммерческая разработка.
Списочек я выдала, но еще попробовала обратить внимание, что не курсы возможно нужны. Делюсь этой частью ответа.
🧑💻🧑💻🧑💻
"Найти курсы" -- это выглядит уже решением, а проблема внутри какая-то другая.
Например:
🔺 новые фичи делаются очень долго
🔺 джуны косячат, сеньоры ругаются
🔺 джуны даже не берутся за задачи с БД
🔺 ревью задач, связанных с БД, занимает вечность
🔺 за последний месяц в продакшене было уже три инцидента с производительностью запросов
🔺 разработчики жалуются, что компания не занимается их развитием
🔺 и т.д.
В каждом из этих случаев "отправить разработчиков на курсы" может оказаться частью решения, но вряд ли первой и наверняка не единственной.
И что делать?
Если все уже проанализировано, проблема сформулирована и разобрана на запчасти, варианты набрейнштормлены, оценены и т.д., и осталось только выбрать хорошего провайдера курсов -- отлично, можно выбирать из моего или других списков курсов.
Но если дотошного анализа проблемы еще не было -- я бы вложилась в анализ. Сначала в одиночку, потом с командой/заинтересованными лицами.
По формату начала бы с факторов, которые участвуют в ситуации, и как они друг на друга влияют.
🧑💻🧑💻🧑💻
-- спросили тут меня.
Контекст -- коммерческая разработка.
Списочек я выдала, но еще попробовала обратить внимание, что не курсы возможно нужны. Делюсь этой частью ответа.
🧑💻🧑💻🧑💻
"Найти курсы" -- это выглядит уже решением, а проблема внутри какая-то другая.
Например:
🔺 новые фичи делаются очень долго
🔺 джуны косячат, сеньоры ругаются
🔺 джуны даже не берутся за задачи с БД
🔺 ревью задач, связанных с БД, занимает вечность
🔺 за последний месяц в продакшене было уже три инцидента с производительностью запросов
🔺 разработчики жалуются, что компания не занимается их развитием
🔺 и т.д.
В каждом из этих случаев "отправить разработчиков на курсы" может оказаться частью решения, но вряд ли первой и наверняка не единственной.
И что делать?
Если все уже проанализировано, проблема сформулирована и разобрана на запчасти, варианты набрейнштормлены, оценены и т.д., и осталось только выбрать хорошего провайдера курсов -- отлично, можно выбирать из моего или других списков курсов.
Но если дотошного анализа проблемы еще не было -- я бы вложилась в анализ. Сначала в одиночку, потом с командой/заинтересованными лицами.
По формату начала бы с факторов, которые участвуют в ситуации, и как они друг на друга влияют.
🧑💻🧑💻🧑💻
👍3💯2👀1
Про использование MySQL в Яндекс.Директе: https://youtu.be/x03CwcLLDW4
А это мой давний доклад на Я.Субботнике про БД.
Рассказ 2017 года, но там уже десятки шардов и десятки терабайт данных; а клёвые инструменты в Директе были вообще всегда.
Три части в рассказе:
🔹Шардинг
🔹DDL на больших и гигантских таблицах
🔹 История обновления данных на основе обработки бинлогов
А это мой давний доклад на Я.Субботнике про БД.
Рассказ 2017 года, но там уже десятки шардов и десятки терабайт данных; а клёвые инструменты в Директе были вообще всегда.
Три части в рассказе:
🔹Шардинг
🔹DDL на больших и гигантских таблицах
🔹 История обновления данных на основе обработки бинлогов
YouTube
004. Опыт использования MySQL в Директе – Елена Большакова
Яндекс — крупнейшая рекламная площадка рунета. Каждый день десятки тысяч рекламодателей и агентств работают в интерфейсе Директа, а число ежедневных обращений к API Директа исчисляется десятками миллионов. Несмотря на большую нагрузку, система стабильно работает…
❤5👍2🔥1🆒1
Противоречие обучения: незнание ступенчато, а узнавание постепенно.
Когда сравниваешь неумеющего себя с умеющим кем-нибудь — видишь разрыв, большую ступеньку: "вот это он умеет, а я нет".
Легко начать мечтать "вот буду учиться, научусь и перепрыгну этот разрыв".
Когда сравниваешь учащегося себя сегодняшнего с собой вчерашним — часто видишь не ступеньку, а маленький кусочек плавного прогресса: "вроде ничего такого не умею сегодня, чего не умел вчера, ну разве что спотыкаюсь меньше". Может быть даже и этого не видишь, а только "не получается, не получается, не получается".
Результат? Перепрыгивания, о котором мечталось, не происходит и не происходит. Мечта "научусь" не сбывается. Грустно!
(Вообще-то не просто грустно, а надо менять этот паттерн. Но про это в другой раз)
Когда сравниваешь неумеющего себя с умеющим кем-нибудь — видишь разрыв, большую ступеньку: "вот это он умеет, а я нет".
Легко начать мечтать "вот буду учиться, научусь и перепрыгну этот разрыв".
Когда сравниваешь учащегося себя сегодняшнего с собой вчерашним — часто видишь не ступеньку, а маленький кусочек плавного прогресса: "вроде ничего такого не умею сегодня, чего не умел вчера, ну разве что спотыкаюсь меньше". Может быть даже и этого не видишь, а только "не получается, не получается, не получается".
Результат? Перепрыгивания, о котором мечталось, не происходит и не происходит. Мечта "научусь" не сбывается. Грустно!
(Вообще-то не просто грустно, а надо менять этот паттерн. Но про это в другой раз)
👍4🔥4👏1🤔1😱1
Разные перспективы
Верхний кадр:
Изучаю новый фреймворк
Ты можешь, ты уже делал это
Нижний кадр:
Смотрю, как кто-то другой изучает фреймворк, который я знаю.
Сюда / Ну давай уже
И этот комикс тоже о том же противоречии обучения: смотришь вперед -- надо преодолевать большое и страшное незнание. Смотришь назад -- вроде ничего такого и не сделал
Верхний кадр:
Изучаю новый фреймворк
Ты можешь, ты уже делал это
Нижний кадр:
Смотрю, как кто-то другой изучает фреймворк, который я знаю.
Сюда / Ну давай уже
И этот комикс тоже о том же противоречии обучения: смотришь вперед -- надо преодолевать большое и страшное незнание. Смотришь назад -- вроде ничего такого и не сделал
👍3🔥2💯1