Теперь, о elasticsearch — если есть необходимость, можно реализовать, или использовать готовый обработчик логов, который сразу будет слать логи в elk.
Например, django-structlog. В нем реализовано почти все, кроме генерации traceid — нужно будет добавлять менеджеры контекста и/или middleware, там где необходимо.
Список того, что делать не следует:
Не логгируйте с помощью print — логи должны приходить туда, где их ожидают. При print, нужно вручную отслеживать контекст приложения, добавлять форматирование, а также передавать io.Stream, если у вас более одного обработчика логов.
Не сериализуйте в prod среде с помощью встроенного json. Он достаточно медленный, если вводные данные не являются объектом io.Stream. Есть достаточное количество оберток над native-библиотеками (orjson, ujson, rapidjson).
Павел, скажите пожалуйста, планируется ли десктоп-клиент, или спецификация bt/ble-комманд для взаемодействия с флиппером, или это останется "фичей" только для ios/android?
При большом упорстве — CPython собирается аналогичным образом. Недавно встраивал в Golang приложение возможность сериализовать python объекты с помощью shared-library.
Я обхожусь прокси с авторотацией. Иногда приходится использовать ещё и puppeteer. Пока проблем с капчей от CloudFlare не возникло, но на некоторых сайтах — важно пробрасывать куки в запрос.
Можно поставить CloudFlare или найти аналогичное решение, но пользователь будет "наслаждаться" капчей...
Все что может быть прочитано — будет прочитано. Относительно недавно пришлось писать парсер для тематического ресурса про киберспорт. С администраций ресурса связывались, но увы, они не имеют реализованного API (только очень старый бекенд закрытый вышеупомянутым). Пришлось использовать lxml и много прокси-серверов для своевременной актуализации данных.
P.S.: Мне кажется что в 2020 было бы хорошей практикой владельцам ресурсов оставлять контакты в футере, или специальной странице, а людям что парсят данные — читать их.
Explicit is better than implicit.
Simple is better than complex.
Не злоупотребляйте лямбдами, если нужен поддерживаемый код. Анонимные функции в некоторых случаях можно применять как колбеки. В подавляющем большинстве случаев стоит передавать именованую функцию/класс в качестве колбека.
Сильно зависит от конфигурации. На прошлой работе коллеги смогли обеспечить комфортную работу в Firefox/Chrome. C com/native-расширениями эта платформа и под Linux/Windows отличной от ПК разработчика — плохо работает.
Если такое количество ядер не нужно на постоянной основе — выгоднее 3700x/xt и аренда мощностей в каком нибудь AWS/Hetzner.
К тому же с 3700 — легче собрать ПК, чем с старшими моделями. Старшие могут выделять много тепла и сложнее подобрать башню, которая не закроет часть слотов для ОЗУ.
P.S. Сам искал конфигурацию для нового ПК и остановился на 3700x, ASRock X570 (почти все модели поддерживают Thunderbolt 3 AIC).
Интересный подход, но необычно видеть Celery и Docker вместе.
Возможно я не верно истолковал посыл статьи, но разве не проще было бы использовать много контейнеров с приложениям (consumer/publisher) без Celery? Docker в этом случае мог бы обеспечить перенаправление логов из stdout, ограничения по ресурсам (CPU, RAM, I/O) и масштабирование путем увеличения ядер/квоты CPU, или увеличением количества контейнеров…
Для production на работе пришли к контейнерам с aio-pika поверх облака с контейнерами.
Мне почему-то кажется, что автор пытается переизобрести opentracing, sentry (beta), или opencensus (beta)…
Теперь, о elasticsearch — если есть необходимость, можно реализовать, или использовать готовый обработчик логов, который сразу будет слать логи в elk.
Например, django-structlog. В нем реализовано почти все, кроме генерации traceid — нужно будет добавлять менеджеры контекста и/или middleware, там где необходимо.
Список того, что делать не следует:
print— логи должны приходить туда, где их ожидают. Приprint, нужно вручную отслеживать контекст приложения, добавлять форматирование, а также передаватьio.Stream, если у вас более одного обработчика логов.json. Он достаточно медленный, если вводные данные не являются объектомio.Stream. Есть достаточное количество оберток над native-библиотеками (orjson, ujson, rapidjson).Павел, скажите пожалуйста, планируется ли десктоп-клиент, или спецификация bt/ble-комманд для взаемодействия с флиппером, или это останется "фичей" только для ios/android?
Стоит опубликовать исходники на GitHub :)
А еще лучше — использовать pathlib.
Попробуйте HTTPie c батарейкой для AWS авторизации.
Жду светлого будущего с nextcloud.
Это ещё цветочки! Моя — из вредности прокусила стекло на новом ноутбуке (матрица осталась цела). Мне — стремно покупать новый монитор "без рамок".
Материнки на x470 с thunderbolt стоили от 400$. На x570 существуют дешевле комплектации.
При большом упорстве — CPython собирается аналогичным образом. Недавно встраивал в Golang приложение возможность сериализовать python объекты с помощью shared-library.
Вероятно, не настроены локали
Попробуйте это:
Будучи студентом, мне было достаточно DroidEdit (хороший редактор) и C4droid. Можно там подсмотреть решения :)
VIM — легкий и работает везде, требует клавиатуру (у меня на asus tf101 — она была).
Я обхожусь прокси с авторотацией. Иногда приходится использовать ещё и puppeteer. Пока проблем с капчей от CloudFlare не возникло, но на некоторых сайтах — важно пробрасывать куки в запрос.
Можно поставить CloudFlare или найти аналогичное решение, но пользователь будет "наслаждаться" капчей...
Все что может быть прочитано — будет прочитано. Относительно недавно пришлось писать парсер для тематического ресурса про киберспорт. С администраций ресурса связывались, но увы, они не имеют реализованного API (только очень старый бекенд закрытый вышеупомянутым). Пришлось использовать lxml и много прокси-серверов для своевременной актуализации данных.
P.S.: Мне кажется что в 2020 было бы хорошей практикой владельцам ресурсов оставлять контакты в футере, или специальной странице, а людям что парсят данные — читать их.
Вроде бы, можно контролировать состояние устройств/endpoint'оа для PJSIP подписавшись на состояние устройств при общении через WebSocket.
Не злоупотребляйте лямбдами, если нужен поддерживаемый код. Анонимные функции в некоторых случаях можно применять как колбеки. В подавляющем большинстве случаев стоит передавать именованую функцию/класс в качестве колбека.
Для случаев с параметризироваными функциями покрываются методом partial из модуля functools:
Сильно зависит от конфигурации. На прошлой работе коллеги смогли обеспечить комфортную работу в Firefox/Chrome. C com/native-расширениями эта платформа и под Linux/Windows отличной от ПК разработчика — плохо работает.
Осторожно. Он довольно горячий при стабильных 4,4 ГГц. Трижды подумайте про охлаждение ;)
Если такое количество ядер не нужно на постоянной основе — выгоднее 3700x/xt и аренда мощностей в каком нибудь AWS/Hetzner.
К тому же с 3700 — легче собрать ПК, чем с старшими моделями. Старшие могут выделять много тепла и сложнее подобрать башню, которая не закроет часть слотов для ОЗУ.
P.S. Сам искал конфигурацию для нового ПК и остановился на 3700x, ASRock X570 (почти все модели поддерживают Thunderbolt 3 AIC).
Интересный подход, но необычно видеть Celery и Docker вместе.
Возможно я не верно истолковал посыл статьи, но разве не проще было бы использовать много контейнеров с приложениям (consumer/publisher) без Celery? Docker в этом случае мог бы обеспечить перенаправление логов из stdout, ограничения по ресурсам (CPU, RAM, I/O) и масштабирование путем увеличения ядер/квоты CPU, или увеличением количества контейнеров…
Для production на работе пришли к контейнерам с aio-pika поверх облака с контейнерами.