А у меня вот такое получилось, правда на Python (ибо Java я варить не умею), но думаю в Java тоже есть "целочисленное деление" .
def humanReadableByteCount(size: int, si : bool) -> str:
unit = 1000 if si else 1024
exp = int(math.log(size)//math.log(unit))
pre = "{}{}".format(("", *("kMGTPE" if si else "KMGTPE"))[exp], ("" if si else "i"))
return "{:.1f} {}B".format(size//(unit**exp/10)/10, pre)
Т.е. вместо деления сразу на 1000, сначала делим на 100, отбрасываем дробную часть, а потом делим ещё на 10. Таким образом при форматировании до 1 знака после запятой нет никаких округлений дробной части в большую сторону.
Сам же OAuth 2.0 — это протокол авторизации, отвечающий за проверку доступов пользователя.
Два ложных утверждения в одном предложении.
Не читайте советских газет русскую википедию - это вредно.
OAuth (Open Authorization[1][2]) is an open standard for access delegation - это не протокол, это стандарт (еще говорят что это фреймворк), и не авторизации а "делегорования доступа". При этом какой именно протокол и какая именно процедура аутентификации (не авторизации) пользователя будет использоваться нигде не регламентируется.
И да, OAuth 2.0 никоим образом не "отвечает за проверку доступов пользователя" - этим каждое приложение занимается самостоятельно.
Сам Keycloak написан на Java. Но так как сейчас в основном используется кроссплатформенность, и .NET Core является ярким представителем таких технологий, почему бы не попробовать интегрироваться с другим языком программирования?
Что за набор слов без смысла. Какая разница на чем написаны 2 разных приложения которые общаются между собой через редиректы пользовательского браузера и через HTTP?
При чем тут кросплатформенность .NET? Какая вообще связть между кросплатформенностью и разными языками программирования?
т.е. примерно 722 "преобразований в секунду на каждый мегагерц тактовой частоты процессора", что конечно чуть медленнее чем 845 у автора, но потратил я на это "решение" времени меньше чем писал этот комментарий.
Ну как бы предсказуемо. Особенно предсказуемо если ты понимаешь что asyncio — это кооперативный event loop.
Ну и как бы в каждой нормальной статье или туториале по asyncio в самом начале пишут, для чего он был придуман.
Предлагаю автору повторить замеры но с измененным профилем нагрузки — не менее 10к долгоживущих HTTP/WebSocket соединений на воркера. Ну или в современных условиях можно и по 100к на воркера. И тогда посмотрим кто кого =)
Из анналов Stack Overflow:
if io_bound:
if io_very_slow:
print("Use Asyncio")
else:
print("Use Threads")
else:
print("Multi Processing")
SOLID — это не про ООП в условной Java — это шире.
Например есть консольная утилита sort — сортирует строки по не убыванию, и много утилит и людей использует её такой какая она есть.
Но тут становится понятно что иногда мы получаем не тот результат что нам нужен:
$ sort << EOF
> 1 one
> 2 two
> 10 ten
> 20 twenty
> EOF
10 ten
1 one
20 twenty
2 two
Нам хочется что бы числа интерпретировались именно как числа при сортировке (а не набор символов) что бы получать "математически правильную" сортировку.
У нас есть 2 пути — нарушить SOLID и изменить поведение утилиты — но тогда десятки/сотни уже написанных утилит (использующих sort) перестанут корректно работать.
Или не нарушать SOLID и расширить функциональность (добавив в данном случае опцию -g):
$ sort -g << EOF
1 one
2 two
10 ten
20 twenty
EOF
1 one
2 two
10 ten
20 twenty
И даже если мы говорим про классы — принцип Open-Close говорит нам, что если у нас есть условный класс Foo в версии 1.0, то в версии 1.1 у него могут появиться новые методы (или опциональные параметры к старым), но старые методы должны работать так как и раньше. И не обязательно для этого создавать новый класс потомок.
По большому счету Open-Close — это про обратную совместимость.
Хотя на практике, наверно, стоит ограничиться 10 пробирками что бы уменьшить человеческий фактор.
Но как написали ниже — это только "в стране розовых пони", ведь непонятно как поведут себя пробы крови (или чего там еще берут) от разных людей при смешивании, а так же уменьшение концентрации положительного образца десятками и сотнями отрицательных.
Если говорить о сетевом трафике, то веб-сокеты отправляют всего два запроса:
GET для получения HTML страницы
UPGRADE для соединения с веб-сокетами
Вебсокеты отправляют ровно один запрос — GET с заголовками Connection: Upgrade и Upgrade: websocket (который Вы, видимо, назвали UPGRADE). А первый GET который Вы упомянули не имеет никакого отношения к установлению вебсокет соединения (как например и куча другий GET запросов где загружаются картинки, CSS и прочие ресурсы).
2)
Ну, если вы открываете соединение на «server 1», затем балансировщик переключает вас на «server 2», вы получите ошибку: «Error during WebSocket handshake: Unexpected response code: 400». Socket.IO решает эту проблему с помощью cookie (или с помощью маршрутизации соединений на основе исходных адресов), а у веб-сокетов не существует подобного механизма.
Вебсокет соединение открывается за 1 HTTP запрос, как балансировщик может сделать переключение на другой сервер посреди запроса? "Это какой-то неправильный балансировщик", как говорил Винни Пух, "и он неправильно балансирует".
С другой стороны если Вы делаете горизонтальное масштабирование через балансировщик HTTP запросов, то в настройке балансировщика должны быть правила "приклеивания" запросов клиента к определенному серверу на основе определенных правил (каких именно — зависит от специфики проекта и возможностей балансировщика). Если Вы это не настраиваете на балансировщике — то плохо открывающиеся вебсокеты — это будет далеко не главная проблема в Вашем проекте.
А поясните, пожалуйста, для новичка — что входит в другие варианты для любительских сайтов, и почему они не могут себе это позволить? И входит ли в этот перечень вариант "работать по старинке без CDN и прочих модных вещей"?
Условно, соискатель тратит 3 часа на написание кода + еще 5 на вылизывание и поиск лучших практик в гугле, а представитель компании за 1 минуту дает вердикт.
Тут смотря что Вы хотите увидеть в выполненном тестовом задании. Обычно в Интернете встречаю упоминания тестовых заданий в которых соискателю предлагалось изобрести какое-либо алгоритмическое ноу-хау (тянущее на научную работу) или супер вызубренное владение каким-то конкретным инструментом/библиотекой/фреймворком.
Однажды нам потребовались дополнительные руки в нашу маленькую команду. В связи с тем что общаться с людьми в живую не мой конёк, то эту задачу на себя взяли другие подходящие люди, а с моей стороны было подготовлено техническое задание для выполнения тестового задания.
На составления ТЗ я потратил около 3-х дней, на выполнение соискателю давался 1 день, на проверку я тратил не менее 1 часа. Задание не было большим и сложным, так почему же я потратил так много времени на подготовку ТЗ?
ТЗ было составлено так, что бы соискатель смог продемонстрировать такие свои навыки:
внимательно читать ТЗ
вникать в предметную область
абстрагироваться на разных уровнях детализации (система/приложение/класс)
банальное понимание клиент-серверной архитектуры (особенно когда на разных уровнях взаимодействия клиент и сервер могут меняться местами)
структурировать дизайн приложения
структурировать код приложения
переиспользовать код
работать с чёрными ящиками (есть детальное описание API другого приложения, но нет его реализации что бы к нему подключиться и интегрироваться последовательностью проб и ошибок)
прочее
При этом в самом же ТЗ и в сопроводительном письме указывалось что код не будет даже компилироваться и запускаться, было описано что это одно из приложений в микросервисной системе, что это "прототип" но подобию которого будут строится и все другие приложения системы, и прочие "намёки".
Так вот на разработку такого тестового задания и на интерпретацию того что нам присылали соискатели тратиться достаточно много времени, понятно что если соискателей много то суммарно их потраченного времени больше чем нашего, но если сравнивать с временем 1 соискателя, то мы потратили на тестовое задание в разы больше времени и сил.
P.S.: рассматривались соискатели именовавшие себя Junior и Middle — все показывали примерно равные уровни компетенции по тем параметрам что мы оценивали.
P.P.S.: и да, то что соискатель делал в тестовом задании было реально схоже с тем что мы делаем на самом деле, т.е. нужно было написать мини игрушечную версию того что у нас имеется.
Вначале я подумал что это очередная статья на тему "я не умею в асинхронный код и слишком часто стреляю себе в ногу — давайте запретим и заменим чем-то новым что не достреливает до моих ног", но потом вспомнил что это перевод и воздержался от подробного разбора.
Не хочу Вас огорчать, но Вы как раз и описали протокол общения телефона с зарядкой. Вот эти самые комбинации напряжений на линиях D+ D- и отдаваемое зарядкой напряжение при определённой комбинации — и есть протокол взаимодействия.
Да, протокол описанный Вами очень "примитивен", это не общение по HTTP как многие думают при слове "протокол", но всё же.
А шунт в делителе и вот это всё остальное — это реализация протокола. Никто не запрещает реализовать это через умный микроконтроллер управляющий DC-DC преобразователем.
Мне понятна "боль" автора от не угасающего чувства что "его опять обманули маркетологи", но в любой ситуации есть много нюансов, в которых не всегда виноваты маркетологи, а, например, незнание школьного курса физики и законы физики, а так же правила электробезопасности и электро-совместимости.
Цитата: "и заряжаются от 5-вольтовых источников тока в 1 А.". И это первое неправильное допущение — зарядки для телефонов это источники напряжения, а не тока, а 1А — это максимальный ток который они могут обеспечить без падения напряжения.
Судить о характеристиках ВСЕХ (большинства) аккумуляторов для смартфонов по паре найденных спецификаций — очень грубо и ошибочно. На практике производятся и используются множество различных типов Li-Ion аккумуляторов использующих разную химию и технологические приёмы — это связано с широким диапазоном условий их эксплуатации (температурные условия, профили и токи разрядки, токи зарядки, пожаробезопасность, типичная глубина разряда и много прочего).
Сравнивать аккумуляторы для смартфонов и типоразмер 18650 — это как сравнивать строительный фен с феном для волос. Хотя аккумуляторы всё же больше похожи между собой чем фены.
А вот сравнивать "быструю зарядку" силовых аккумуляторов для электроинструмента Bosch и смартфонов — это уже точно "строительный фен против фена для волос". Тип, размер, вес, условия эксплуатации и зарядки — абсолютно разные.
Измерять характеристики зарядки аккумулятора прибором который ставиться в разрыв USB провода — это полный fail. Единственное что может показать этот прибор — это сколько денег стоит один раз зарядить этот телефон (умножив насчитанное прибором количество кВт*ч на Ваш тариф за электричество).
Хотя должен отметить что прибор хорош — понимает 9В а не только стандартные USB 5В.
Делать вывод о практически нулевой деградации аккумулятора по количеству энергии на входе в телефон с припиской "с учетом того, что часть взятого из розетки рассеялась на кабеле"? А КПД преобразователя контроллера заряда? А нагрев и рассеивание тепловой энергии аккумулятором при зарядке?
В чём суть претензий — ёмкость аккумулятора — это характеристика на отдачу энергии из аккумулятора наружу, а не приём её внутрь. И измерять её можно исключительно став прибором в разрыв контактов самого аккумулятора.
Из практики — попались мне китайские аккумуляторы, на которых было написано 3000mAh, при зарядке через ЗУ Turnigy прибор показал что внутрь аккумулятора залито около 3500mAh. Но при контрольной разрядке количество отданной энергии колебалось всего от 200 до 300 mAh в зависимости от тока разрядки. Т.е. разница между потреблённой энергией аккумулятором при зарядке и отданной при разрядке больше чем десятикратная.
Так же себя ведёт любой деградировавший аккумулятор — он начинает потреблять больше а отдавать меньше.
Потому Ваши выводы о "практически нулевой деградации" на основе потреблённой энергии — полная профанация.
А теперь к реальной практике и Quick Charge (tm).
В реальной практике имеем Xiaomi с 3000мАч аккумулятором, штатной зарядкой на 2А и поддержкой QC3 (Quick Charge 3 версии). И iPhone7 с штатной зарядкой на 1А (возможно с поддержкой каких либо проприетарных протоколов быстрой зарядки).
На зарядку Xiaomi от 10% до 100% от 2А штатного ЗУ уходит около 3-4 часов времени. Телефон не греется.
От QC3 зарядки до 60-70% он заряжается за 25-30 минут, при этом греется как сковородка.
После любого из типов зарядок время автономной работы Xiaomi одинаково. QC3 зарядка используется редко (только когда выходить через 20 минут, а заряда <20% осталось), при постоянном использовании возможна быстрая деградация аккумулятора из-за перегревания.
При этом после единократного акта зарядки iPhone7 от 2А ЗУ телефон нагрелся как сковородка, а время автономной работы телефона резко уменьшилось до 4-6 часов вместо полного рабочего дня (более 12 часов).
После "восстановительной терапии" в виде использования исключительно штатной зарядки на 1А аккумулятор вернул былые силы и вновь обеспечивает 12+ часов автономной работы.
Про смысл Quick Charge (tm) и других проприетарных протоколов быстрой зарядки — все они нацелены НЕ на особый способ заталкивания энергии в аккумулятор, а про способ передачи от ЗУ до контроллера зарядки как можно больше энергии через стандартный USB шнур.
Вся проблема в том что после превышения 2А тонкие проводочки внутри USB шнура начинают сильно греться и на них теряется очень много энергии и вольтаж на входе в телефон начинает просидать ниже 5В. Та же проблема проявляется при использовании дешёвых шнуров или сильно длинных — время зарядки сильно увеличивается, так как телефону приходиться уменьшать свои аппетиты дабы поддерживать стабильные 5В на входе. Именно по той же причине шнурки что идут в комплекте со всеми хорошими Power Bank устройствами — короткие и с толстыми медными жилами внутри.
Эта проблема очень просто решается повышением напряжения (именно так передают электроэнергию по магистралям в 10кВ, 100кВ и более), но в то же время сложно решаема из-за нарушения USB стандарта. Так как если стандартный на вид USB разъём в который можно включить стандартный USB шнур и подключить к любому USB устройству будет выдавать 9В вместо 5В, то "глупый массовый потребитель" очень быстро спалит все USB устройства в своём доме, после чего пойдёт судиться с производителем такого USB зарядного устройства.
Тут и появляются протоколы типа Quick Charge (tm):
— (телефон) А дай ка мне побольше и повкуснее!
— (QC зарядка) Могу дать 9В, а ты то выдержишь столько?
— (телефон) Давай сюда! Ещё не такое выдерживали! Ом-ном-ном. Вкусно то как, но всё ещё мало, давай добавки!
— (QC зарядка) Могу ещё досыпать до 12В, это ж уже дофига, точно выдержишь???
— (телефон) Выдержу-выдержу… Давай все 12В! Ом-ном-ном… А температура аккумулятора всего 43*С, давай ещё, жадина!
— (QC зарядка) Ну как просите, вот Вам 20В сейчас дам, достаточно для ваших аппетитов?
— (телефон) Эээ… Стоп! Стоп! Какие 20В? Я же так волшебный чёрный дым наружу выпущу!
Для чего создавать отдельную генератор-функцию, внутри которой изобретать велосипед с прерываемым бесконечным циклом, если абсолютно ту же функциональность даёт встроенный open:
for line in open('big_file.txt', 'r', encoding='utf-8'):
# process line
Плюс при объяснениях таких простых тем необходимо, для новичков, уточнять что это для текстовых файлов, а функция с именем начинающимся с get_ не возвращает data_from_big_file, а возвращает генератор.
У Вас ещё wrapper дополнительно вызывает другой метод — что в Python весьма не бесплатно.
Т. е. содержимое методов _coroutine_exception_handler и _sync_exception_handler по хорошему бы переместить внутрь объявления самих wrapper функций.
А у меня вот такое получилось, правда на Python (ибо Java я варить не умею), но думаю в Java тоже есть "целочисленное деление" .
Т.е. вместо деления сразу на 1000, сначала делим на 100, отбрасываем дробную часть, а потом делим ещё на 10. Таким образом при форматировании до 1 знака после запятой нет никаких округлений дробной части в большую сторону.
Есть большое подозрение что это были не эмуляторы а симуляторы. Тогда сравниваем мягкое с тёплым.
Хорошо, на одном конце линии супер крутые транзисторы для преобразования AC->DC.
А обратно? DC->AC? По старинке крутятся мотор+генератор?
Два ложных утверждения в одном предложении.
Не читайте
советских газетрусскую википедию - это вредно.OAuth (Open Authorization[1][2]) is an open standard for access delegation - это не протокол, это стандарт (еще говорят что это фреймворк), и не авторизации а "делегорования доступа". При этом какой именно протокол и какая именно процедура аутентификации (не авторизации) пользователя будет использоваться нигде не регламентируется.
И да, OAuth 2.0 никоим образом не "отвечает за проверку доступов пользователя" - этим каждое приложение занимается самостоятельно.
Что за набор слов без смысла. Какая разница на чем написаны 2 разных приложения которые общаются между собой через редиректы пользовательского браузера и через HTTP?
При чем тут кросплатформенность .NET? Какая вообще связть между кросплатформенностью и разными языками программирования?
ну не знаю, такой вот аксесуар очень даже не абсурдный
https://www.thuraya.com/en/support/upgrades/legacy/thuraya-satsleeve-for-iphone
Вроде такого?
Ноутбук с Intel® Core(TM) i5-8265U CPU @ 1.60GHz
Python 3.7 (тот язык что "тормозной")
т.е. примерно 722 "преобразований в секунду на каждый мегагерц тактовой частоты процессора", что конечно чуть медленнее чем 845 у автора, но потратил я на это "решение" времени меньше чем писал этот комментарий.
Вы имели ввиду использовать flock но не на отдельных файлах на PID файлах?
Тогда согласен.
А как же правило "не изобретай велосипед"?
Как минимум по двум пунктам:
Ну как бы предсказуемо. Особенно предсказуемо если ты понимаешь что asyncio — это кооперативный event loop.
Ну и как бы в каждой нормальной статье или туториале по asyncio в самом начале пишут, для чего он был придуман.
Предлагаю автору повторить замеры но с измененным профилем нагрузки — не менее 10к долгоживущих HTTP/WebSocket соединений на воркера. Ну или в современных условиях можно и по 100к на воркера. И тогда посмотрим кто кого =)
Из анналов Stack Overflow:
Не обязательно.
SOLID — это не про ООП в условной Java — это шире.
Например есть консольная утилита
sort— сортирует строки по не убыванию, и много утилит и людей использует её такой какая она есть.Но тут становится понятно что иногда мы получаем не тот результат что нам нужен:
Нам хочется что бы числа интерпретировались именно как числа при сортировке (а не набор символов) что бы получать "математически правильную" сортировку.
У нас есть 2 пути — нарушить SOLID и изменить поведение утилиты — но тогда десятки/сотни уже написанных утилит (использующих
sort) перестанут корректно работать.Или не нарушать SOLID и расширить функциональность (добавив в данном случае опцию
-g):И даже если мы говорим про классы — принцип Open-Close говорит нам, что если у нас есть условный класс Foo в версии 1.0, то в версии 1.1 у него могут появиться новые методы (или опциональные параметры к старым), но старые методы должны работать так как и раньше. И не обязательно для этого создавать новый класс потомок.
По большому счету Open-Close — это про обратную совместимость.
С учетом нелинейности роста соотношения количества пробирок к количеству проб — это выглядит не так и плохо.
Хотя на практике, наверно, стоит ограничиться 10 пробирками что бы уменьшить человеческий фактор.
Но как написали ниже — это только "в стране розовых пони", ведь непонятно как поведут себя пробы крови (или чего там еще берут) от разных людей при смешивании, а так же уменьшение концентрации положительного образца десятками и сотнями отрицательных.
Прошу прощения, но:
1)
Вебсокеты отправляют ровно один запрос —
GETс заголовкамиConnection: UpgradeиUpgrade: websocket(который Вы, видимо, назвалиUPGRADE). А первый GET который Вы упомянули не имеет никакого отношения к установлению вебсокет соединения (как например и куча другий GET запросов где загружаются картинки, CSS и прочие ресурсы).2)
Вебсокет соединение открывается за 1 HTTP запрос, как балансировщик может сделать переключение на другой сервер посреди запроса? "Это какой-то неправильный балансировщик", как говорил Винни Пух, "и он неправильно балансирует".
С другой стороны если Вы делаете горизонтальное масштабирование через балансировщик HTTP запросов, то в настройке балансировщика должны быть правила "приклеивания" запросов клиента к определенному серверу на основе определенных правил (каких именно — зависит от специфики проекта и возможностей балансировщика). Если Вы это не настраиваете на балансировщике — то плохо открывающиеся вебсокеты — это будет далеко не главная проблема в Вашем проекте.
А поясните, пожалуйста, для новичка — что входит в другие варианты для любительских сайтов, и почему они не могут себе это позволить? И входит ли в этот перечень вариант "работать по старинке без CDN и прочих модных вещей"?
Тут смотря что Вы хотите увидеть в выполненном тестовом задании. Обычно в Интернете встречаю упоминания тестовых заданий в которых соискателю предлагалось изобрести какое-либо алгоритмическое ноу-хау (тянущее на научную работу) или супер вызубренное владение каким-то конкретным инструментом/библиотекой/фреймворком.
Однажды нам потребовались дополнительные руки в нашу маленькую команду. В связи с тем что общаться с людьми в живую не мой конёк, то эту задачу на себя взяли другие подходящие люди, а с моей стороны было подготовлено техническое задание для выполнения тестового задания.
На составления ТЗ я потратил около 3-х дней, на выполнение соискателю давался 1 день, на проверку я тратил не менее 1 часа. Задание не было большим и сложным, так почему же я потратил так много времени на подготовку ТЗ?
ТЗ было составлено так, что бы соискатель смог продемонстрировать такие свои навыки:
При этом в самом же ТЗ и в сопроводительном письме указывалось что код не будет даже компилироваться и запускаться, было описано что это одно из приложений в
микросервисной системе, что это "прототип" но подобию которого будут строится и все другие приложения системы, и прочие "намёки".Так вот на разработку такого тестового задания и на интерпретацию того что нам присылали соискатели тратиться достаточно много времени, понятно что если соискателей много то суммарно их потраченного времени больше чем нашего, но если сравнивать с временем 1 соискателя, то мы потратили на тестовое задание в разы больше времени и сил.
P.S.: рассматривались соискатели именовавшие себя Junior и Middle — все показывали примерно равные уровни компетенции по тем параметрам что мы оценивали.
P.P.S.: и да, то что соискатель делал в тестовом задании было реально схоже с тем что мы делаем на самом деле, т.е. нужно было написать мини игрушечную версию того что у нас имеется.
Вначале я подумал что это очередная статья на тему "я не умею в асинхронный код и слишком часто стреляю себе в ногу — давайте запретим и заменим чем-то новым что не достреливает до моих ног", но потом вспомнил что это перевод и воздержался от подробного разбора.
Не хочу Вас огорчать, но Вы как раз и описали протокол общения телефона с зарядкой. Вот эти самые комбинации напряжений на линиях D+ D- и отдаваемое зарядкой напряжение при определённой комбинации — и есть протокол взаимодействия.
Да, протокол описанный Вами очень "примитивен", это не общение по HTTP как многие думают при слове "протокол", но всё же.
А шунт в делителе и вот это всё остальное — это реализация протокола. Никто не запрещает реализовать это через умный микроконтроллер управляющий DC-DC преобразователем.
Мне понятна "боль" автора от не угасающего чувства что "его опять обманули маркетологи", но в любой ситуации есть много нюансов, в которых не всегда виноваты маркетологи, а, например, незнание школьного курса физики и законы физики, а так же правила электробезопасности и электро-совместимости.
Цитата: "и заряжаются от 5-вольтовых источников тока в 1 А.". И это первое неправильное допущение — зарядки для телефонов это источники напряжения, а не тока, а 1А — это максимальный ток который они могут обеспечить без падения напряжения.
Судить о характеристиках ВСЕХ (большинства) аккумуляторов для смартфонов по паре найденных спецификаций — очень грубо и ошибочно. На практике производятся и используются множество различных типов Li-Ion аккумуляторов использующих разную химию и технологические приёмы — это связано с широким диапазоном условий их эксплуатации (температурные условия, профили и токи разрядки, токи зарядки, пожаробезопасность, типичная глубина разряда и много прочего).
Сравнивать аккумуляторы для смартфонов и типоразмер 18650 — это как сравнивать строительный фен с феном для волос. Хотя аккумуляторы всё же больше похожи между собой чем фены.
А вот сравнивать "быструю зарядку" силовых аккумуляторов для электроинструмента Bosch и смартфонов — это уже точно "строительный фен против фена для волос". Тип, размер, вес, условия эксплуатации и зарядки — абсолютно разные.
Измерять характеристики зарядки аккумулятора прибором который ставиться в разрыв USB провода — это полный fail. Единственное что может показать этот прибор — это сколько денег стоит один раз зарядить этот телефон (умножив насчитанное прибором количество кВт*ч на Ваш тариф за электричество).
Хотя должен отметить что прибор хорош — понимает 9В а не только стандартные USB 5В.
Делать вывод о практически нулевой деградации аккумулятора по количеству энергии на входе в телефон с припиской "с учетом того, что часть взятого из розетки рассеялась на кабеле"? А КПД преобразователя контроллера заряда? А нагрев и рассеивание тепловой энергии аккумулятором при зарядке?
В чём суть претензий — ёмкость аккумулятора — это характеристика на отдачу энергии из аккумулятора наружу, а не приём её внутрь. И измерять её можно исключительно став прибором в разрыв контактов самого аккумулятора.
Из практики — попались мне китайские аккумуляторы, на которых было написано 3000mAh, при зарядке через ЗУ Turnigy прибор показал что внутрь аккумулятора залито около 3500mAh. Но при контрольной разрядке количество отданной энергии колебалось всего от 200 до 300 mAh в зависимости от тока разрядки. Т.е. разница между потреблённой энергией аккумулятором при зарядке и отданной при разрядке больше чем десятикратная.
Так же себя ведёт любой деградировавший аккумулятор — он начинает потреблять больше а отдавать меньше.
Потому Ваши выводы о "практически нулевой деградации" на основе потреблённой энергии — полная профанация.
А теперь к реальной практике и Quick Charge (tm).
В реальной практике имеем Xiaomi с 3000мАч аккумулятором, штатной зарядкой на 2А и поддержкой QC3 (Quick Charge 3 версии). И iPhone7 с штатной зарядкой на 1А (возможно с поддержкой каких либо проприетарных протоколов быстрой зарядки).
На зарядку Xiaomi от 10% до 100% от 2А штатного ЗУ уходит около 3-4 часов времени. Телефон не греется.
От QC3 зарядки до 60-70% он заряжается за 25-30 минут, при этом греется как сковородка.
После любого из типов зарядок время автономной работы Xiaomi одинаково. QC3 зарядка используется редко (только когда выходить через 20 минут, а заряда <20% осталось), при постоянном использовании возможна быстрая деградация аккумулятора из-за перегревания.
При этом после единократного акта зарядки iPhone7 от 2А ЗУ телефон нагрелся как сковородка, а время автономной работы телефона резко уменьшилось до 4-6 часов вместо полного рабочего дня (более 12 часов).
После "восстановительной терапии" в виде использования исключительно штатной зарядки на 1А аккумулятор вернул былые силы и вновь обеспечивает 12+ часов автономной работы.
Про смысл Quick Charge (tm) и других проприетарных протоколов быстрой зарядки — все они нацелены НЕ на особый способ заталкивания энергии в аккумулятор, а про способ передачи от ЗУ до контроллера зарядки как можно больше энергии через стандартный USB шнур.
Вся проблема в том что после превышения 2А тонкие проводочки внутри USB шнура начинают сильно греться и на них теряется очень много энергии и вольтаж на входе в телефон начинает просидать ниже 5В. Та же проблема проявляется при использовании дешёвых шнуров или сильно длинных — время зарядки сильно увеличивается, так как телефону приходиться уменьшать свои аппетиты дабы поддерживать стабильные 5В на входе. Именно по той же причине шнурки что идут в комплекте со всеми хорошими Power Bank устройствами — короткие и с толстыми медными жилами внутри.
Эта проблема очень просто решается повышением напряжения (именно так передают электроэнергию по магистралям в 10кВ, 100кВ и более), но в то же время сложно решаема из-за нарушения USB стандарта. Так как если стандартный на вид USB разъём в который можно включить стандартный USB шнур и подключить к любому USB устройству будет выдавать 9В вместо 5В, то "глупый массовый потребитель" очень быстро спалит все USB устройства в своём доме, после чего пойдёт судиться с производителем такого USB зарядного устройства.
Тут и появляются протоколы типа Quick Charge (tm):
— (телефон) А дай ка мне побольше и повкуснее!
— (QC зарядка) Могу дать 9В, а ты то выдержишь столько?
— (телефон) Давай сюда! Ещё не такое выдерживали! Ом-ном-ном. Вкусно то как, но всё ещё мало, давай добавки!
— (QC зарядка) Могу ещё досыпать до 12В, это ж уже дофига, точно выдержишь???
— (телефон) Выдержу-выдержу… Давай все 12В! Ом-ном-ном… А температура аккумулятора всего 43*С, давай ещё, жадина!
— (QC зарядка) Ну как просите, вот Вам 20В сейчас дам, достаточно для ваших аппетитов?
— (телефон) Эээ… Стоп! Стоп! Какие 20В? Я же так волшебный чёрный дым наружу выпущу!
Серьёзно? "Не учите детей плохому!" (с)
Для чего создавать отдельную генератор-функцию, внутри которой изобретать велосипед с прерываемым бесконечным циклом, если абсолютно ту же функциональность даёт встроенный
open:Плюс при объяснениях таких простых тем необходимо, для новичков, уточнять что это для текстовых файлов, а функция с именем начинающимся с
get_не возвращаетdata_from_big_file, а возвращает генератор.У Вас ещё
wrapperдополнительно вызывает другой метод — что в Python весьма не бесплатно.Т. е. содержимое методов
_coroutine_exception_handlerи_sync_exception_handlerпо хорошему бы переместить внутрь объявления самихwrapperфункций.