Forwarded from Ivan Ugliansky
А следующий эпизод будет в четверг: 24.10.24, в 21:00 по Нск/19:00 по Екб/17:00 по Мск, вот здесь:
https://www.youtube.com/live/KIvIlGxGhx0
Кроме ютьюба постараемся и напрямую сюда сделать трансляцию, а то с ним нынче бывает трудно.
Гостей не будет, будем мы с Сашей сидеть, трещать за жизнь и преподавание под пиво. Обсудим, что поменялось за последнее время и вообще "how it started, how it's going". Приходите послушать и/или составить нам компанию)
https://www.youtube.com/live/KIvIlGxGhx0
Кроме ютьюба постараемся и напрямую сюда сделать трансляцию, а то с ним нынче бывает трудно.
Гостей не будет, будем мы с Сашей сидеть, трещать за жизнь и преподавание под пиво. Обсудим, что поменялось за последнее время и вообще "how it started, how it's going". Приходите послушать и/или составить нам компанию)
YouTube
Вторая пересдача #16
❤🔥11👍6❤1
Стой под стрелой
Удивительное устройство Эпл Воч. Они уже месяц ежедневно предупреждают меня, что ночью будут ставить обновление, но поскольку основной их юз-кейс — трекинг сна, то ночью они обычно на руке и никакого обновления не ставят (не подключен к питанию). И не то…
Возможно, это рассчитано на таких, как я: людей, которые не использую Эпл Воч для трекинга сна (а то потом придется статистику прочитать, да и сами часы что-нибудь недоброе скажут, типа "кажется, вы забыли лечь спать, постарайтесь так больше не делать", зачем такой стресс?).
Возможно, внутри Эпл за это отвечают такие же дурачки, как я, в этом и разгадка. Но вообще, да, проблема скорее системная: у меня что айфон, что часы нифига не обновляются по ночам, хотя стоят на зарядке, их прям упрашивать надо. Я лично всегда думал, что это разработчики опять с таймзонами не справились.
Эх, если бы внутри Эпл был кто-то, кто бы сообразил, что часы-трекер сна не должны ставить обновления по ночам. Этот человек сразу на пару ступеней повышение бы получил.
Возможно, внутри Эпл за это отвечают такие же дурачки, как я, в этом и разгадка. Но вообще, да, проблема скорее системная: у меня что айфон, что часы нифига не обновляются по ночам, хотя стоят на зарядке, их прям упрашивать надо. Я лично всегда думал, что это разработчики опять с таймзонами не справились.
❤2
Подумалось: насколько фаззинг (в данном контексте - генерация случайным образом корректных входных программ) хорош для поиска компиляторных багов, но настолько же он бесполезен для поиска проблем в рантайме (багов в GC, синхронизации и т.д.).
Это, конечно, очень понятно: компилятор (хороший) стабилен и всегда работает одинаково на одних и тех же входных данных, чтобы найти проблемы вам нужно добавить случайности именно в то, что вы компилируете. Фаззер здесь божественен.
Рантайм же по своей сути работает со случайными событиями. Как именно операционная система выдавала вашим тредам кванты для работы? Кто из потоков в результате выиграл гонку за lock? Как это повлияло на скорость аллокации объектов? А это в свою очередь на момент, в которой случилась сборка мусора, и на расположение объектов в памяти к этому моменту. Это я еще не говорю про влияние других процессов, которое, конечно, тоже есть: GC вполне может ориентироваться на общее потребление памяти в системе, да и опять таки, кванты то им тоже выдаются, т.е. общая загруженность системы может радикально повлиять на всю картину происходящего в рантайме.
Конечно же, можно сказать, что все это в конце концов детерминировано, просто влияющих факторов очень много. Но какая разница, если при каждом новом запуске мы получаем все новые события? Все это напоминает старый, как жизнь, спор: "существует ли у человека свобода выбора или любой наш выбор предрешен, пусть и огромным количеством факторов?". Лично для меня здесь нет никакого противоречия: глобальный детерминизм логичен, но в условиях невозможности наблюдения всех первопричин это не имеет никакого значения, а значит можно считать, что свобода выбора существует. Вот и получается, что GC с рантаймом - тоже в определенном смысле наделены такой свободой, характером и удачей.
Ну и какой же тут может быть толк от фаззера? Случайность, которую он порождает на порядок меньше той, с которой мы сталкиваемся в рантайме при прокачке гигабайтов памяти средним таким приложением на спринге. Гораздо полезнее для нас варировать паттерны поведения операционной системы, например, рандомно менять приоритеты тредам, как в chaos mode чудесного отладчика rr, или же полностью подменить планировщик на свой, как это сделано в Hermit, и уже в него добавлять свою, контролируемую случайность. Вот это и правда может вскрыть очень сложные, спорадичные баги в рантайме, т.к. путь исполнения будет максимально нетипичен, даже для такой хаотичной системы.
Забавно, что вот эти chaos моды добавляют тулы, которые как раз создавались для уменьшения недетерменизма и помощи в отладке (чтобы дать стабильный способ воспроизведения спорадичной проблемы). Но оказывается, что когда борешься с хаосом, со временем начинаешь неплохо понимать, как его можно создавать самостоятельно. Нахожу это очень поэтичным.
#дух_машины
Это, конечно, очень понятно: компилятор (хороший) стабилен и всегда работает одинаково на одних и тех же входных данных, чтобы найти проблемы вам нужно добавить случайности именно в то, что вы компилируете. Фаззер здесь божественен.
Рантайм же по своей сути работает со случайными событиями. Как именно операционная система выдавала вашим тредам кванты для работы? Кто из потоков в результате выиграл гонку за lock? Как это повлияло на скорость аллокации объектов? А это в свою очередь на момент, в которой случилась сборка мусора, и на расположение объектов в памяти к этому моменту. Это я еще не говорю про влияние других процессов, которое, конечно, тоже есть: GC вполне может ориентироваться на общее потребление памяти в системе, да и опять таки, кванты то им тоже выдаются, т.е. общая загруженность системы может радикально повлиять на всю картину происходящего в рантайме.
Конечно же, можно сказать, что все это в конце концов детерминировано, просто влияющих факторов очень много. Но какая разница, если при каждом новом запуске мы получаем все новые события? Все это напоминает старый, как жизнь, спор: "существует ли у человека свобода выбора или любой наш выбор предрешен, пусть и огромным количеством факторов?". Лично для меня здесь нет никакого противоречия: глобальный детерминизм логичен, но в условиях невозможности наблюдения всех первопричин это не имеет никакого значения, а значит можно считать, что свобода выбора существует. Вот и получается, что GC с рантаймом - тоже в определенном смысле наделены такой свободой, характером и удачей.
Ну и какой же тут может быть толк от фаззера? Случайность, которую он порождает на порядок меньше той, с которой мы сталкиваемся в рантайме при прокачке гигабайтов памяти средним таким приложением на спринге. Гораздо полезнее для нас варировать паттерны поведения операционной системы, например, рандомно менять приоритеты тредам, как в chaos mode чудесного отладчика rr, или же полностью подменить планировщик на свой, как это сделано в Hermit, и уже в него добавлять свою, контролируемую случайность. Вот это и правда может вскрыть очень сложные, спорадичные баги в рантайме, т.к. путь исполнения будет максимально нетипичен, даже для такой хаотичной системы.
Забавно, что вот эти chaos моды добавляют тулы, которые как раз создавались для уменьшения недетерменизма и помощи в отладке (чтобы дать стабильный способ воспроизведения спорадичной проблемы). Но оказывается, что когда борешься с хаосом, со временем начинаешь неплохо понимать, как его можно создавать самостоятельно. Нахожу это очень поэтичным.
#дух_машины
Wikipedia
Фаззинг
Фа́ззинг (англ. fuzzing или англ. fuzz testing, буквально «испытание пушинками/волосинками», от англ. fuzz — с изначальным значением «делать неопрятным», «с прилипшими волосками», затем переносным «затуманивать», «путать»), также тестирование мусорными данными…
🔥16
This media is not supported in your browser
VIEW IN TELEGRAM
Про Линуса уже только ленивый не написал, конечно, но как такое игнорировать?
Другими словами: "вы мне еще за русско-финскую ответите, суки" и "опенсорс, он кому надо опенсорс, понятно?".
As to sending me a revert patch - please use whatever mush you call brains. I'm Finnish. Did you think I'd be *supporting* Russian aggression? Apparently it's not just lack of real news, it's lack of history knowledge too.
Другими словами: "вы мне еще за русско-финскую ответите, суки" и "опенсорс, он кому надо опенсорс, понятно?".
😁25🍌3💯1
погнали на вторую пересдачу: https://www.youtube.com/live/KIvIlGxGhx0
YouTube
Вторая пересдача #16
❤7
Forwarded from Кулешов разгоняет
Так, с мест передают смешное, кто-то пытается выпилить Линуса из Линукса.
😁9🤣2👍1🤩1
Забежал в универ мимоходом в нетипичное для себя время, а тут просто огромная концентрация сиспрошников разных курсов на квадратный метр. Приятно ☺️
Хорошего всем дня!
Хорошего всем дня!
❤24❤🔥3👍1
Наконец, важный вопрос. Может мне бороду сбрить?
Anonymous Poll
23%
Бороду долой
36%
Ни в коем случае
41%
Поспорить с кем-то, поставив на кон бороду, а дальше все решит случай
Обещал тут порассказывать про свои самые злые кранчи. Кажется, сегодня просто идеально подходящий для этого вечер! (начинающаяся осенняя хандра, временное состояние отца-одиночки и просто миллион дел на эту неделю - атмосфера что надо).
---
Итак, кранч первый, пост-студенческий.
Немного контекста: в универе у меня был диплом про то, как сделать из консервативного сборщика мусора точный. В JVM со странным рантаймом, лишь наполовину написанном на managed языке, чём-то типа Java.
Опишу суть в паре предложений. Если супер упростить, то трассирующая сборка мусора в managed языке - это такой DFS: нужно выбрать объекты, которые 100% живы, и найти всех достижимых из них по ссылкам. Все, что вы не нашли - это и есть мусор. Есть небольшая проблемка: граф большеват - миллионы объектов, а обойти его нужно очень быстро - за миллисекунды. Отсюда и куча классных алгоритмов, как это делать эффективно, или по кускам, или параллельно с работой приложения, или еще как.
Но есть еще вопрос с тем, что такое "выбрать объекты, которые 100% живы". Как собственно это сделать? Ну, вот, например, локалы, которые еще будут использовать в будущем: ссылки в них то всяко живы, объекты, на которые они ссылаются - тоже. А как их найти в скомпилированном коде? На каких они регистрах, в каких стековых слотах? Тут есть два подхода:
1) Спросить у компилятора, он точно знает (он же этот код сгенерил!). Он вам может записать структуры данных, в которых будет сказано: "вот в этой точке в коде на rdx лежит ссылка на живой объект, начинай-ка разметку с нее". Понятны с этим проблемы: нужно тормозить треды только в этих специальных точках, а не где попало, для этих точек генерить какую-то метаинфу (а она ведь место занимает), и уже по ней GC будет находить гарантированно живые объекты,
2) Забить на компилятор. Консервативно предполагать, что любой регистр и любой стековый слот содержит указатель на объект, а потом (зная структуру памяти и особенности работы аллокатора) отсеивать всякий мусор. Так делают, когда хотят прикрутить GC к C++, например (там то откуда вам знать: лежит ли у вас на стеке просто чиселко или указатель, приходится падать в консерватизм).
Тут плюсы и минусы тоже понятны: с одной стороны никакой тебе метаинфы лишней и тормози треды (почти) где хочешь, с другой - консерватизм чреват ошибками. Объекты, которые давно померли могут быть признаны живыми, а это потенциально может привести к бесконечному потреблению памяти. Ну, как "потенциально", именно это и случалось у некоторых наших клиентов.
Собственно, что мне нужно было сделать: перейти от подхода консервативного GC, который по историческим причинам был у нас сделан, к точному GC. При этом постараться не слишком драматично просадить производительность, но главное - добиться корректности.
Это в свою очередь было не так просто в том числе и из-за хитрого рантайма, который лишь наполовину был написан на managed языке (там не так то просто гарантировать, что исполнение дойдет до safe-point за разумное время).
Ну и дополнительной сложностью было то, что такой работой никто в общем-то не занимается. Ну т.е. да, есть классические статьи Ole Agesen, где в общих чертах описано все, что нужно сделать. Но там a) нет кучи технических деталей, б) там рантайм то обычный, т.е. со многими основательными проблемами реализации никто и не сталкивался раньше (в SubstrateVM столкнулись, но у нас с ними получились прям разные решения).
Короче, задача то в целом довольно инженерная, совсем не rocket science, но чтобы ее сделать нужно просто огромный масштаб изменений провести в рамках кодовой базы JVM, прям с нуля ввести концепции, которых раньше в этой кодовой базе никогда и не было (хотя бы даже safe-points).
Так что в сумме (с перерывами на поход в enterprise и поиск себя) ушло у меня на это дело полтора года: половину на прототипирование (так появляется диплом бакалавра), половину на продуктизацию и решения проблем с рантаймом (так появляется диплом магистра).
Что-то не получилось рассказать контекст за пару предложений, но что поделать) Давайте переходить к кранчу ↓
#дух_машины
---
Итак, кранч первый, пост-студенческий.
Немного контекста: в универе у меня был диплом про то, как сделать из консервативного сборщика мусора точный. В JVM со странным рантаймом, лишь наполовину написанном на managed языке, чём-то типа Java.
Опишу суть в паре предложений. Если супер упростить, то трассирующая сборка мусора в managed языке - это такой DFS: нужно выбрать объекты, которые 100% живы, и найти всех достижимых из них по ссылкам. Все, что вы не нашли - это и есть мусор. Есть небольшая проблемка: граф большеват - миллионы объектов, а обойти его нужно очень быстро - за миллисекунды. Отсюда и куча классных алгоритмов, как это делать эффективно, или по кускам, или параллельно с работой приложения, или еще как.
Но есть еще вопрос с тем, что такое "выбрать объекты, которые 100% живы". Как собственно это сделать? Ну, вот, например, локалы, которые еще будут использовать в будущем: ссылки в них то всяко живы, объекты, на которые они ссылаются - тоже. А как их найти в скомпилированном коде? На каких они регистрах, в каких стековых слотах? Тут есть два подхода:
1) Спросить у компилятора, он точно знает (он же этот код сгенерил!). Он вам может записать структуры данных, в которых будет сказано: "вот в этой точке в коде на rdx лежит ссылка на живой объект, начинай-ка разметку с нее". Понятны с этим проблемы: нужно тормозить треды только в этих специальных точках, а не где попало, для этих точек генерить какую-то метаинфу (а она ведь место занимает), и уже по ней GC будет находить гарантированно живые объекты,
2) Забить на компилятор. Консервативно предполагать, что любой регистр и любой стековый слот содержит указатель на объект, а потом (зная структуру памяти и особенности работы аллокатора) отсеивать всякий мусор. Так делают, когда хотят прикрутить GC к C++, например (там то откуда вам знать: лежит ли у вас на стеке просто чиселко или указатель, приходится падать в консерватизм).
Тут плюсы и минусы тоже понятны: с одной стороны никакой тебе метаинфы лишней и тормози треды (почти) где хочешь, с другой - консерватизм чреват ошибками. Объекты, которые давно померли могут быть признаны живыми, а это потенциально может привести к бесконечному потреблению памяти. Ну, как "потенциально", именно это и случалось у некоторых наших клиентов.
Собственно, что мне нужно было сделать: перейти от подхода консервативного GC, который по историческим причинам был у нас сделан, к точному GC. При этом постараться не слишком драматично просадить производительность, но главное - добиться корректности.
Это в свою очередь было не так просто в том числе и из-за хитрого рантайма, который лишь наполовину был написан на managed языке (там не так то просто гарантировать, что исполнение дойдет до safe-point за разумное время).
Ну и дополнительной сложностью было то, что такой работой никто в общем-то не занимается. Ну т.е. да, есть классические статьи Ole Agesen, где в общих чертах описано все, что нужно сделать. Но там a) нет кучи технических деталей, б) там рантайм то обычный, т.е. со многими основательными проблемами реализации никто и не сталкивался раньше (в SubstrateVM столкнулись, но у нас с ними получились прям разные решения).
Короче, задача то в целом довольно инженерная, совсем не rocket science, но чтобы ее сделать нужно просто огромный масштаб изменений провести в рамках кодовой базы JVM, прям с нуля ввести концепции, которых раньше в этой кодовой базе никогда и не было (хотя бы даже safe-points).
Так что в сумме (с перерывами на поход в enterprise и поиск себя) ушло у меня на это дело полтора года: половину на прототипирование (так появляется диплом бакалавра), половину на продуктизацию и решения проблем с рантаймом (так появляется диплом магистра).
Что-то не получилось рассказать контекст за пару предложений, но что поделать) Давайте переходить к кранчу ↓
#дух_машины
🔥10👍3
И вот: дипломы написаны, защиты пройдены, студенческие шапки подброшены в воздух. Плюс еще пара месяцев потрачена на окончательную продуктизацию диплома, полишинг и базовое локальное тестирование. Близится самое интересное и ответственное: момент ОГРОМНОГО коммита всех правок в транк. Вы, конечно, можете сейчас подушнить и сказать: "ты чего, нужно было по кускам коммитать!", но это и так уже были куски, так вот первый кусок был все еще огромным, как чертов авианосец.
Наконец, день X (дальше тянуть нельзя): я прохожу последние локальные тесты, просматриваю каждый из сотен измененных файлов вручную (я уже тогда был параноиком) и зажмурившись... вливаю все в транк.
У меня была некоторая уверенность в том, что в целом то все работает, я действительно много и под нагрузкой тестировал в последние месяцы. Но, конечно, настоящая проверка - это огромное ночное тестирование с очень разными сценариями, которое шло по ночам на всех наших машинах одновременно (да, мы тогда были небольшой компанией, у которой не было лишних денег, так что по ночам девелоперские тачки тоже гоняли тесты).
И вот я иду домой (а в этот момент и начинается ночная сборка). Дома сижу и через remote desktop смотрю на то, как сборка продвигается на разных машинах. Пока что до исполнения дело не дошло, так что переживать рано, но я, конечно, все равно очень волнуюсь. В конце концов я засыпаю только для того, чтобы утром побежать на работу (даже не глядя на статус сборки), чтобы уже там оценить последствия. Сажусь за свою машину (пока что в офисе никого нет), кажется, у меня есть пара писем от работавшего ночью QA (святой человек был), медленно начинаю смотреть на статус сборки, и...
Следующий месяц своей жизни я помню смутно, он прошел, как в тумане.
В общем, я развалил нахрен приблизительно все. Вообще. При том спорадичными багами, которые умело избегали обнаружения на локальном тестировании. Уже ночью на меня завели пару ишуев, а весь наступивший день (да и пару следующих) на меня продолжали создавать все новые и новые critical и blocker. Потом, видимо, стали жалеть и просто дописывать новые тестовые сценарии в уже существующие тикеты.
Замечу, что это никак не аффектало клиентов, но вот другие разработчики просто не могли нормально тестировать свои правки: у них все падало из-за меня. Это безумно давило мне на психику, мало того, что у меня все разваливалось, так и другим людям я реально мешал работать.
Вы, наверное, скажете, что логичным шагом было бы откатить огромную правку и продолжить локальное тестирование (благо информацию о падающих сценариях я собрал). Но честь и хвала моему лиду, он решил тогда дать мне время на отладку. Первые, самые легко воспроизводимые баги я отладил за пару-тройку дней (в которые я, конечно, херачил часов по 18). После этого сборка чуть ожила, хотя в каком-то смысле все стало только страшнее: оставшиеся баги были уже не так просты, дать какой-то гарантии на время их отладки я не мог, workaround предложить тоже не мог, а если бы я откатил, то потерял бы сценарии для воспроизведения уже насовсем, слишком уж они спорадичны! Именно тогда я впервые встретился с багом, который воспроизводился раз в год (как я узнал еще через 11 месяцев).
В целом то я к тому времени уже что-то умел в отладке, но этот месяц что-то изменил во мне кардинально: я отлаживал столько таких злых спорадичных багов, я делал это настолько постоянно (на работе, дома, на парах в аспирантуре, в транспорте, когда шел за кофе, в редкие минуты, когда выбирался погулять воздухом), что в какой-то момент я с ними породнился что ли. Познал дзен, если можно так сказать в ситуации, когда на тебя косо смотрят все твои комрады, у которых опять что-то упало из-за тебя. Ну, и реально научился отлаживать.
Через месяц сборка окончательно (хе-хе, так нельзя говорить в случае спорадичных багов, это тоже урок, который я усвоил) позеленела, я выдохнул, команда тоже. ↓
#дух_машины
Наконец, день X (дальше тянуть нельзя): я прохожу последние локальные тесты, просматриваю каждый из сотен измененных файлов вручную (я уже тогда был параноиком) и зажмурившись... вливаю все в транк.
У меня была некоторая уверенность в том, что в целом то все работает, я действительно много и под нагрузкой тестировал в последние месяцы. Но, конечно, настоящая проверка - это огромное ночное тестирование с очень разными сценариями, которое шло по ночам на всех наших машинах одновременно (да, мы тогда были небольшой компанией, у которой не было лишних денег, так что по ночам девелоперские тачки тоже гоняли тесты).
И вот я иду домой (а в этот момент и начинается ночная сборка). Дома сижу и через remote desktop смотрю на то, как сборка продвигается на разных машинах. Пока что до исполнения дело не дошло, так что переживать рано, но я, конечно, все равно очень волнуюсь. В конце концов я засыпаю только для того, чтобы утром побежать на работу (даже не глядя на статус сборки), чтобы уже там оценить последствия. Сажусь за свою машину (пока что в офисе никого нет), кажется, у меня есть пара писем от работавшего ночью QA (святой человек был), медленно начинаю смотреть на статус сборки, и...
Следующий месяц своей жизни я помню смутно, он прошел, как в тумане.
В общем, я развалил нахрен приблизительно все. Вообще. При том спорадичными багами, которые умело избегали обнаружения на локальном тестировании. Уже ночью на меня завели пару ишуев, а весь наступивший день (да и пару следующих) на меня продолжали создавать все новые и новые critical и blocker. Потом, видимо, стали жалеть и просто дописывать новые тестовые сценарии в уже существующие тикеты.
Замечу, что это никак не аффектало клиентов, но вот другие разработчики просто не могли нормально тестировать свои правки: у них все падало из-за меня. Это безумно давило мне на психику, мало того, что у меня все разваливалось, так и другим людям я реально мешал работать.
Вы, наверное, скажете, что логичным шагом было бы откатить огромную правку и продолжить локальное тестирование (благо информацию о падающих сценариях я собрал). Но честь и хвала моему лиду, он решил тогда дать мне время на отладку. Первые, самые легко воспроизводимые баги я отладил за пару-тройку дней (в которые я, конечно, херачил часов по 18). После этого сборка чуть ожила, хотя в каком-то смысле все стало только страшнее: оставшиеся баги были уже не так просты, дать какой-то гарантии на время их отладки я не мог, workaround предложить тоже не мог, а если бы я откатил, то потерял бы сценарии для воспроизведения уже насовсем, слишком уж они спорадичны! Именно тогда я впервые встретился с багом, который воспроизводился раз в год (как я узнал еще через 11 месяцев).
В целом то я к тому времени уже что-то умел в отладке, но этот месяц что-то изменил во мне кардинально: я отлаживал столько таких злых спорадичных багов, я делал это настолько постоянно (на работе, дома, на парах в аспирантуре, в транспорте, когда шел за кофе, в редкие минуты, когда выбирался погулять воздухом), что в какой-то момент я с ними породнился что ли. Познал дзен, если можно так сказать в ситуации, когда на тебя косо смотрят все твои комрады, у которых опять что-то упало из-за тебя. Ну, и реально научился отлаживать.
Через месяц сборка окончательно (хе-хе, так нельзя говорить в случае спорадичных багов, это тоже урок, который я усвоил) позеленела, я выдохнул, команда тоже. ↓
#дух_машины
🔥17👍4
Это был самый настоящий кранч, при том в каждый момент времени у меня не было понимания, вижу ли я свет в конце тоннеля или это поезд на меня летит нет. Закончится ли эта отладка когда-нибудь или нет? А ведь в какой-то момент мне уже и лид стал говорить аккуратно, но жестко говорить, что если если я до такого-то числа все не отлажу, то это уже будет совсем плохо, и придется откатывать. Откатывать результат предыдущих полутора лет моей работы, да.
Естественно, это все плохо сказывалось на мне: я мало спал (даже для меня), хреново выглядел (хуже, чем обычно), огрызался в разговорах с окружающими. Наверное, это сильно контрастировало с тем уверенным выпускником маги, который на защите сказал: "вот теперь начинается самое интересное, не переключайтесь!".
Стоило ли оно все того? Я до сих пор думаю, что да.
Это был кранч во благо: именно он научил меня отлаживать и главное - любить отлаживать. Без этого кранча не было бы одного из очень важных моих инженерных достижений (точнее первого его кирпичика). А еще он научил меня, как писать более надежный код в рантайме, ведь многих багов можно было бы избежать, перестрахуйся я на этапе разработки лишний раз. Да и с командой меня это сильно сблизило: да, они ворчали, но поддерживали как могли, да и стерпели же все-таки. А лиду я до сих пор благодарен, что он тогда в меня поверил и дал этот месяц.
—
Но, конечно, далеко не все кранчи в результате оказываются полезными. В следующий раз расскажу о совсем другой истории, хоть и тоже связанной с разработкой GC. Там все получилось прям по классике, так что happy end-а не ждите.
А пока: не забывайте отдыхать и трогать траву, думаю ее еще можно найти на улице даже у нас :)
#дух_машины
Естественно, это все плохо сказывалось на мне: я мало спал (даже для меня), хреново выглядел (хуже, чем обычно), огрызался в разговорах с окружающими. Наверное, это сильно контрастировало с тем уверенным выпускником маги, который на защите сказал: "вот теперь начинается самое интересное, не переключайтесь!".
Стоило ли оно все того? Я до сих пор думаю, что да.
Это был кранч во благо: именно он научил меня отлаживать и главное - любить отлаживать. Без этого кранча не было бы одного из очень важных моих инженерных достижений (точнее первого его кирпичика). А еще он научил меня, как писать более надежный код в рантайме, ведь многих багов можно было бы избежать, перестрахуйся я на этапе разработки лишний раз. Да и с командой меня это сильно сблизило: да, они ворчали, но поддерживали как могли, да и стерпели же все-таки. А лиду я до сих пор благодарен, что он тогда в меня поверил и дал этот месяц.
—
Но, конечно, далеко не все кранчи в результате оказываются полезными. В следующий раз расскажу о совсем другой истории, хоть и тоже связанной с разработкой GC. Там все получилось прям по классике, так что happy end-а не ждите.
А пока: не забывайте отдыхать и трогать траву, думаю ее еще можно найти на улице даже у нас :)
#дух_машины
🔥30❤3👍1
Сегодня встретил в кофейне старую знакомую, а она в разговоре: "ну, как у тебя дела? как обычно - хреново?" 😂
Надо что-то делать с репутацией, не иначе)
Надо что-то делать с репутацией, не иначе)
😢11😁9💔5