Задать вопрос
  • Для чего нужен интерфейс смарт-контракта?

    @Tyavochka
    Solidity Developer
    Интерфейс необходим для вызова любой функции контракта из клиента или другого контракта.
    В вызов входит сигнатура метода - первые 4 байта хеша от имени функции и ее параметров (без возвращаемого значения).
    В большинстве случаев у вас есть весь контракт и нет необходимости выделять отдельно интерфейс.
    Интерфейс может помочь унифицировать код, а также пригодится там, где точно неизвестна реализация контракта - например нужна работа с любыми токенами, которые поддерживают ERC20.
    Еще интерфейс будет полезен для всяких грязных хаков с fallback функциями и delegatecall (proxy) - когда вызов идет через промежуточный контракт.
    Ответ написан
    1 комментарий
  • Не тривиальный пример библиотеки Logger в python?

    @deliro
    Несколько лет назад я (видимо, как и ты) уверовал в logging. Ведь не зря же там такие дикие и глубокие настройки: и форматтеры есть, и хэндлеры есть, да и фильтры какие-то. И подумал я: крутые программисты всё это используют, а я на задворках рынка побираюсь.

    И начал с тех пор настраивать все мыслимые и немыслимые настройки logging. Все ошибки у меня были в соответствующих файлах для ошибок. Также, был лог с дебаговой инфой. Всё это группировалось по файлам. Дебаг форматировался одним форматтером, ошибочный лог — другим форматтером, более подробным. И всё это росло, цвело и пахло.

    Реальность оказалась жестокой. Все эти форматтеры оказались абузой — грепать логи стало сложней. Отдельные файлы с дебагом и ошибками оказались абузой — ведь проще грепнуть по уровню лога ( | grep ERROR). В куче файлов логов — чёрт ногу сломит. Да и вообще, логи почти всегда оказывались ненужными — ошибки летят в Sentry, а статистика собирается другими механизмами (prometheus). А ротацию и архивирование логов сделали девопсы.

    А вот хорошие практики, которые я вынес:
    1. Возьми loguru, которому буквально не нужны настройки:

    from loguru import logger
    ...
    # Где-то настроил sink-файл (либо будет только stdout)
    ...
    logger.debug("hello")


    2. Иногда удобно логи вести в JSON-формате. Отпадает необходимость придумывать хитрые grep'ы, всё отлично фильтруется с помощью jq

    3. Ошибки надо не логировать, а слать в Sentry. Желательно, если Sentry настроен на веб-хуки в какой-нибудь slack/discord, чтобы ты видел ошибку в ту же секунду, как она произошла. В Sentry должен быть порядок.

    4. Статистику по логам не стоит строить. Для этого есть куда более удобные и быстрые инструменты от обычных баз данных до prometheus + grafana

    5. Куча файлов логов — в топку. Один файл

    6. Ротация логов желательно должна быть извне

    7. Используй ELK

    8. Используй тесты и дебаггер

    Если резюмировать: на логи возлагают слишком большие надежды и ожидания. Логи — это побочный продукт, который ОЧЕНЬ РЕДКО помогает расследовать неожиданное поведение, причём, очень неудобным способом. Чаще всего, логами обкладывается недостаточно нужной информации и много ненужной информации. И в момент аварии логов не хватает, на то ведь она и авария — её нельзя предусмотреть. Вместо логгирования в большинстве случаев удобнее использовать другие инструменты. Также, советую ознакомиться с этим https://sobolevn.me/2020/03/do-not-log
    Ответ написан
    1 комментарий