Довольно часто на стадии "разбираться и фиксить" есть возможность разбить исходную гипотезу на гипотезы поменьше, сформулировать их в новых тестах, и таким образом найти причину проблемы.
А как насчет "дебага тестами"? Лично я при наличии возможности стараюсь прибегать именно к нему.
Его суть сводится к тому, чтобы формулировать гипотезы о правильной работе кода в виде тестов. Когда тест падает — разбираться и фиксить. Киллер-фича этого подхода состоит в том, что после отладки остается куча артефактов в виде тестов, которые повысят надежность разработки в будущем.
Обещали сравнение, но нормального сравнения по итогу так и не дали. Все сравнение с K3S ограничивается:
Он имеет меньший размер двоичного кода, чем Microk8s, и предлагает более минималистичный набор функций. Однако Microk8s обеспечивает лучшую поддержку различных плагинов для хранения данных и сетей и обладает более полным набором функций из коробки.
Какой размер двоичного кода в том и другом случае? Какие функции из коробки есть в Microk8s, которых нет в K3S? Что значит "лучшая поддержка плагинов", плагины поддерживаются или нет? О каких плагинах речь, с какими из них будут проблемы, а с какими нет?
Питон конкретно в вопросе таких ошибок наоборот очень хорош, мало какой язык из коробки предоставляет настолько информативные и понятные трейсы с распечаткой стэка и всяким подобным. Он даже подчеркивает конкретное место в строке, где случилась ошибка, что очень полезно в случае развесистых выражений.
Тем не менее, я согласен с тем, что питон не лучший первый язык. Для начала лучше разобраться с более низкоуровневыми концепциями, которые лучше видны из какого-нибудь Си, а затем уже можно и наращивать уровни абстракции и удобств. Питон - это про удобства, а они для обучения скорее вредны.
так что со следующего месяца — или ты работаешь больше, или мы тебя увольняем
Нравится или нет, но во многих компаниях это суровая правда жизни. Компании именно так частенько и поступают, это гораздо выгоднее для них, чем нанимать больше сотрудников.
А почему вы считаете, что ровно такое же по форме «или платите больше, или я уйду» должно нравиться начальству и оно должно на него соглашаться?
Оно не должно нравиться. В самой сути отношений работника и работодателя заложен конфликт интересов, где выигрыш работника обычно эквивалентен проигрышу работодателя. Работодателю при прочих равных никогда не будет нравиться платить больше. Он будет делать только если придется, если другого выхода нет.
В действительности в реальной жизни офферы формата "платите за Х больше или услуга перестанет оказываться" встречается сплошь и рядом. Вам так ежегодно "индексируют" квартплату, именно в таком формате в целом в экономике растут цены. Ближайший супермаркет не дает себе труда подумать о категорическом императиве Канта прежде чем повысить цены на туалетную бумагу, а вот работник - самое незащищенное звено в этой цепочке - почему-то вдруг должен.
Тут много хороших идей, часть из них я реализовал, а часть не буду.
Метод wait начиная с версии 0.0.11 является универсальным. По умолчанию он полностью синхронный, но если туда передать опциональным аргументом is_async=True, то метод можно эвейтить. await token выглядит красиво, но пока не реализовано. Возможно, когда-нибудь в будущем это случится, и я готов принимать PRы.
По поводу sleep. В действительности все проверки не прогоняются каждый цикл ивентлупа. Они прогоняются раз в промежуток времени, указанный пользователем как step. По умолчанию это действительно 0.0001 секунды в текущей реализации, однако его можно изменить, если кажется нужным. Чем реже проверки будут происходить - тем "дешевле" это будет для процессора, но тем сильнее можно "переспать" момент отмены.
Само по себе ожидание через sleep или что-то похожее (в нашем случае для асинхронного варианта используется asyncio.sleep), к сожалению, неизбежно, если мы хотим сделать универсальную библиотеку, а не заточенную конкретно под async. Если пойти по пути полной оптимизации под async, то для обычного питона она, к сожалению, станет работать хуже, то есть либо медленнее, либо с более распухшим API, дублирующим основные функции. Дело в том, что существует довольно много причин, по которым токен может быть отменен. Это может быть выполнение произвольного условия, вызов у токена метода cancel(), а также наступление любого из этих событий в любом из вложенных токенов. Некоторые кейсы, например вызов cancel(), действительно можно было бы более эффективно с асинхронной точки зрения обработать, засунув внутрь метода, скажем, вызов коллбека, который отменит какой-то из ожидабельных примитивов asyncio. Однако в этом случае библиотека для обычного, не асинхронного кода, начнет работать медленнее, а именно обычному коду я предпочитаю отдавать приоритет. Я практически не вижу способов сделать это красиво, не отъедая перфоманс у обычного (не async) варианта использования и не переусложняя код библиотеки.
По поводу автоотмены CounterToken, в нем уже по умолчанию была защита от скручивания теми запросами, которые он делает себе сам. Вот пример кода:
По поводу синхронности примера кода, готов принимать PRы с более красивыми примерами, но вообще у меня стояла цель просто показать, что что-то можно эвейтить, более сложная реализация в примере кода, на мой взгляд, обычно излишня.
А в чем уникальность этой "идеи"? Сама по себе идея юзать некоторое количество более слабых ИИ для контроля более сильного довольно очевидна и приходит в голову чуть ли не первой. У того же Бострома в его книжке довольно детально расписаны стратегии, как это можно было бы сделать, вместе с ограничениями и рисками такого подхода. Если вкратце, абсолютной надежности такие методы не дают.
Ну я вот айтишник и никакого отношения к металлургии не имею, но на будущее для себя запомнил, на случай, если вдруг возьмусь проектировать небоскреб, про эту чудо-сталь. В жизни всякое бывает.
Он не сериализуется для передачи другому процессу. Но даже если бы да, я бы не рекомендовал это использовать, инструмент предназначен только для многопоточки.
Вообще, я подумываю над тем, чтобы добавить поддержку процессов. Хотя это с высокой вероятностью придется выносить в отдельный инструмент.
Довольно часто на стадии "разбираться и фиксить" есть возможность разбить исходную гипотезу на гипотезы поменьше, сформулировать их в новых тестах, и таким образом найти причину проблемы.
А как насчет "дебага тестами"? Лично я при наличии возможности стараюсь прибегать именно к нему.
Его суть сводится к тому, чтобы формулировать гипотезы о правильной работе кода в виде тестов. Когда тест падает — разбираться и фиксить. Киллер-фича этого подхода состоит в том, что после отладки остается куча артефактов в виде тестов, которые повысят надежность разработки в будущем.
Cut the prose, please.
Возможно, это так только на силиконовых маках, но лично у меня Inkscape постоянно глючит и вылетает.
А че вообще по деньгам? Насколько дорого обойдется весь такой сетап? И сколько стоят расходники для конкретного изделия - на грамм или как-то иначе?
Обещали сравнение, но нормального сравнения по итогу так и не дали. Все сравнение с K3S ограничивается:
Какой размер двоичного кода в том и другом случае? Какие функции из коробки есть в Microk8s, которых нет в K3S? Что значит "лучшая поддержка плагинов", плагины поддерживаются или нет? О каких плагинах речь, с какими из них будут проблемы, а с какими нет?
Короче, тема не раскрыта.
Но:
Фух, я уж было подумал, что-то нужно делать.
Как?
С таким названием я ожидал что-то реально интересное типа реального кластера из нескольких компьютеров. А по факту тупо настройка докер компоуза.
Питон конкретно в вопросе таких ошибок наоборот очень хорош, мало какой язык из коробки предоставляет настолько информативные и понятные трейсы с распечаткой стэка и всяким подобным. Он даже подчеркивает конкретное место в строке, где случилась ошибка, что очень полезно в случае развесистых выражений.
Тем не менее, я согласен с тем, что питон не лучший первый язык. Для начала лучше разобраться с более низкоуровневыми концепциями, которые лучше видны из какого-нибудь Си, а затем уже можно и наращивать уровни абстракции и удобств. Питон - это про удобства, а они для обучения скорее вредны.
Атом и сейчас прекрасен.
Нравится или нет, но во многих компаниях это суровая правда жизни. Компании именно так частенько и поступают, это гораздо выгоднее для них, чем нанимать больше сотрудников.
Оно не должно нравиться. В самой сути отношений работника и работодателя заложен конфликт интересов, где выигрыш работника обычно эквивалентен проигрышу работодателя. Работодателю при прочих равных никогда не будет нравиться платить больше. Он будет делать только если придется, если другого выхода нет.
В действительности в реальной жизни офферы формата "платите за Х больше или услуга перестанет оказываться" встречается сплошь и рядом. Вам так ежегодно "индексируют" квартплату, именно в таком формате в целом в экономике растут цены. Ближайший супермаркет не дает себе труда подумать о категорическом императиве Канта прежде чем повысить цены на туалетную бумагу, а вот работник - самое незащищенное звено в этой цепочке - почему-то вдруг должен.
Тут много хороших идей, часть из них я реализовал, а часть не буду.
Метод
waitначиная с версии 0.0.11 является универсальным. По умолчанию он полностью синхронный, но если туда передать опциональным аргументомis_async=True, то метод можно эвейтить.await tokenвыглядит красиво, но пока не реализовано. Возможно, когда-нибудь в будущем это случится, и я готов принимать PRы.По поводу
sleep. В действительности все проверки не прогоняются каждый цикл ивентлупа. Они прогоняются раз в промежуток времени, указанный пользователем какstep. По умолчанию это действительно0.0001секунды в текущей реализации, однако его можно изменить, если кажется нужным. Чем реже проверки будут происходить - тем "дешевле" это будет для процессора, но тем сильнее можно "переспать" момент отмены.Само по себе ожидание через
sleepили что-то похожее (в нашем случае для асинхронного варианта используется asyncio.sleep), к сожалению, неизбежно, если мы хотим сделать универсальную библиотеку, а не заточенную конкретно под async. Если пойти по пути полной оптимизации под async, то для обычного питона она, к сожалению, станет работать хуже, то есть либо медленнее, либо с более распухшим API, дублирующим основные функции. Дело в том, что существует довольно много причин, по которым токен может быть отменен. Это может быть выполнение произвольного условия, вызов у токена методаcancel(), а также наступление любого из этих событий в любом из вложенных токенов. Некоторые кейсы, например вызовcancel(), действительно можно было бы более эффективно с асинхронной точки зрения обработать, засунув внутрь метода, скажем, вызов коллбека, который отменит какой-то из ожидабельных примитивов asyncio. Однако в этом случае библиотека для обычного, не асинхронного кода, начнет работать медленнее, а именно обычному коду я предпочитаю отдавать приоритет. Я практически не вижу способов сделать это красиво, не отъедая перфоманс у обычного (не async) варианта использования и не переусложняя код библиотеки.По поводу автоотмены
CounterToken, в нем уже по умолчанию была защита от скручивания теми запросами, которые он делает себе сам. Вот пример кода:В статье я посчитал такие подробности излишними.
По поводу синхронности примера кода, готов принимать PRы с более красивыми примерами, но вообще у меня стояла цель просто показать, что что-то можно эвейтить, более сложная реализация в примере кода, на мой взгляд, обычно излишня.
А логирование не в телеграм-ботах чем-то принципиально отличается от вышеописанного?
А в чем уникальность этой "идеи"? Сама по себе идея юзать некоторое количество более слабых ИИ для контроля более сильного довольно очевидна и приходит в голову чуть ли не первой. У того же Бострома в его книжке довольно детально расписаны стратегии, как это можно было бы сделать, вместе с ограничениями и рисками такого подхода. Если вкратце, абсолютной надежности такие методы не дают.
Ну я вот айтишник и никакого отношения к металлургии не имею, но на будущее для себя запомнил, на случай, если вдруг возьмусь проектировать небоскреб, про эту чудо-сталь. В жизни всякое бывает.
Да, это хорошая идея, я добавил такую возможность для всех токенов, можете попробовать.
Он не сериализуется для передачи другому процессу. Но даже если бы да, я бы не рекомендовал это использовать, инструмент предназначен только для многопоточки.
Вообще, я подумываю над тем, чтобы добавить поддержку процессов. Хотя это с высокой вероятностью придется выносить в отдельный инструмент.
Мне понравилось это замечание, таймаут на запрос как-то упустил в процессе подготовки статьи. Поправил пример кода.
Верно.