Недавно взял Meizu 21 Note, он внезапно оказался отличным, лучшим телефоном из тех, что у меня были. Минуса 2: в РФ не оч стабильная связь, связано с недостатком бендов — гаджет не предназначался для РФ; камера не оч.
С программистами все тоже пугающе плохо. Где-то читал исследование, что средний IQ программиста в России - 108 баллов. Когда я в должной мере осознал этот факт, у меня очень многие вещи встали на свои места. У ПОЛОВИНЫ программистов IQ где-то ниже 108. Многие концепции в программировании просто не доступны большинству программистов.
Довольно часто на стадии "разбираться и фиксить" есть возможность разбить исходную гипотезу на гипотезы поменьше, сформулировать их в новых тестах, и таким образом найти причину проблемы.
А как насчет "дебага тестами"? Лично я при наличии возможности стараюсь прибегать именно к нему.
Его суть сводится к тому, чтобы формулировать гипотезы о правильной работе кода в виде тестов. Когда тест падает — разбираться и фиксить. Киллер-фича этого подхода состоит в том, что после отладки остается куча артефактов в виде тестов, которые повысят надежность разработки в будущем.
Обещали сравнение, но нормального сравнения по итогу так и не дали. Все сравнение с 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ы с более красивыми примерами, но вообще у меня стояла цель просто показать, что что-то можно эвейтить, более сложная реализация в примере кода, на мой взгляд, обычно излишня.
А это по итогу дало какую-то выгоду? Накручено много ложной машинерии — это точно проще, чем иметь несколько варинтов SVG?
Недавно взял Meizu 21 Note, он внезапно оказался отличным, лучшим телефоном из тех, что у меня были. Минуса 2: в РФ не оч стабильная связь, связано с недостатком бендов — гаджет не предназначался для РФ; камера не оч.
По последнему вопросу. Дело тут не в том, что придется начинать заново, а в том, что при этом у вас на диске остается лежать паразитный файл.
Можно ли было метакласс заменить на дескрипторы? И зачем прибивать гвоздями сторонний логгер?
Очень интересно было бы почитать про уход в айтишный менеджмент, минуя позицию тимлида.
А выводы-то какие по итогу? Да, автор познал некоторые базовые идеи под капотом у баз данных, я правда рад за него, но в чем тут ценность для меня?
С программистами все тоже пугающе плохо. Где-то читал исследование, что средний IQ программиста в России - 108 баллов. Когда я в должной мере осознал этот факт, у меня очень многие вещи встали на свои места. У ПОЛОВИНЫ программистов IQ где-то ниже 108. Многие концепции в программировании просто не доступны большинству программистов.
Довольно часто на стадии "разбираться и фиксить" есть возможность разбить исходную гипотезу на гипотезы поменьше, сформулировать их в новых тестах, и таким образом найти причину проблемы.
А как насчет "дебага тестами"? Лично я при наличии возможности стараюсь прибегать именно к нему.
Его суть сводится к тому, чтобы формулировать гипотезы о правильной работе кода в виде тестов. Когда тест падает — разбираться и фиксить. Киллер-фича этого подхода состоит в том, что после отладки остается куча артефактов в виде тестов, которые повысят надежность разработки в будущем.
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ы с более красивыми примерами, но вообще у меня стояла цель просто показать, что что-то можно эвейтить, более сложная реализация в примере кода, на мой взгляд, обычно излишня.
А логирование не в телеграм-ботах чем-то принципиально отличается от вышеописанного?