Как документирование ошибок может позиционировать вас как лидера.

Содержание
1. Как выглядит запись в журнале ошибок?
2. Зачем документировать баги?
3. Хью Лори :)
4. Примеры из моей заначки: в основном проблемы с docker и pandas.
5. Резюме

вступление

На протяжении всей моей карьеры инженера-программиста, а затем специалиста по данным, я продолжал вести журнал ошибок и соответствующих исправлений.

Надеюсь, в конце этого поста вы убедитесь, что записывать беспорядок, который вы устроили, — это великолепно!

Как выглядит запись

Каждое сообщение об ошибке — это напоминание, которое содержит:
а. Что привело к поломке системы
b. В чем заключалась ошибка (включая любые трассировки стека, если они существуют)
c. Что было исправлено (включая любые ссылки на внешние документы)

Зачем документировать?

Почему я документирую свои ошибки в долгоживущем списке?
Я нахожу это очень ценным с нескольких точек зрения:

  1. Те же преимущества, что и у любого ведения дневника — возможность оглянуться назад, чувство выполненного долга. У меня есть баги с моего первого места работы, как-то неловко смотреть на себя с прыщами в подростковом возрасте, но в то же время есть потенциал для признания роста.
  2. Воспроизведение исправления — вы исправили некоторую конфигурацию в неудачной сборке. В идеале вы должны были это .gitted, и в случае, если это произойдет с коллегой, вы можете просто отправить ей ссылку на коммит. Если вы забыли или просто не почувствовали, что документация относится к системе контроля версий, просто отправьте им свое примечание.
  3. Оттачивайте свои навыки письма — часто нам нужно предоставить различную документацию. Процесс перегонки жука в компоненты, о которых я упоминал, — это способ отработать очень важные способности. Бонусные баллы за творческий подход к написанию, ограничивая себя только 1/2 ругательствами. +100 очков навыков за написание поста на Medium 🙂
  4. Позиционируйте себя как лидера — начните документировать другие процессы. Будь тем, к кому обращаются другие, когда дела идут ка-бум. Предупредите свою команду заранее о возможных ловушках в будущем.

Побочный анекдот

Вот еще один момент, который может найти отклик у других начинающих писателей.
Хью Лори, актер, сыгравший удивительно циничного доктора Грегори «Хауса», включая множество других ролей (посмотрите «Блэклэддер», чтобы посмотреть потрясающую британскую комедию (мем прилагается)!), написал книгу под названием «Пистолет». Продавец».

Это одна из моих любимых книг (ссылка на Amazon), и она мне очень понравилась. В интервью Хью упомянул о склонности к ведению журналов. Из-за своего скучного графика в то время он начал приукрашивать некоторые факты, пока в какой-то момент его дневник не стал напоминать жизнь Джеймса Бонда с легким отношением мистера Бина. Этот персонаж стал главным героем его книги.

Кто знает, может быть, когда-нибудь ваш журнал ошибок станет кибер-триллером!

Без дальнейших прощаний,

Мой собственный тайник ОШИБОК

3.3.22 — Не удается создать образ Docker

Я собирал образ докера из Dockerfile репозитория.
Сборка образа докера зависла из-за тайм-аутов от tensorflow во время:

pip install — no-cache-dir -r requirements.txt

Я настоятельно рекомендую флаг no-cache-dir (почему?) в Dockerfiles, потому что он уменьшает размер образа Docker.

Исправлено:

  1. Изменен базовый образ контейнера на «slim-buster»
    Возможно, в текущем базовом образе нет предварительно собранных двоичных файлов для «тонкой» версии, что вызвало компиляцию в собственный код. Это может вызвать большую задержку, которая может объяснить тайм-аут. ЭТО РЕШИЛО ПРОБЛЕМУ
  2. Обновите pip, прежде чем переходить к установке pip
    ЗАПУСТИТЬ установку pip — обновить pip
    При обновлении pip будут обновлены разные файлы .wheels (файл .wheel?) этого pip можно использовать для установки. Один из новых найденных файлов .wheel, вероятно, содержал готовые двоичные файлы в установочном пакете, которые подходили для моего тонкого образа. ЭТО РЕШИЛО ПРОБЛЕМУ

3.2.22 — Неисправный фрейм данных

Выполнял различные вычисления в DataFrame панды и собирал другой фрейм данных на основе строк из оригинала.

Собранный фрейм данных имел странное поведение, подсчет логического столбца возвращал неправильные результаты.

Основная логика:

  1. Создание пустого фрейма данных()
  2. Добавить строки из исходного фрейма данных в новый daraframe

Исправить:

Вместо создания пустого DataFrame

df = DataFrame()

Создайте фрейм данных с идентичными типами столбцов, как у оригинала, например:

df = DataFrame(columns=orig_df.columns)

Наблюдение:

Типы столбцов нового фрейма данных отличались от исходных. Это было свидетельством, которое привело меня к исправлению.

2.2.22 — Не удается передать переменные среды в док-контейнер через командную строку

Это расстроило меня на пару часов.

Я попытался передать доступ AWS и секретные ключи к контейнеру Docker с помощью следующей команды:

тег docker run -e env

Исправить:

Измените порядок параметров, сначала env!!!

тег запуска docker -e env

Краткое содержание

Есть много способов развиваться как инженеру, и я думаю, что документирование для ваших собственных целей и для других — один из них. Это может быть даже забавно, действуя как выход для вашего накопившегося разочарования.

Цитирую мой дорогой друг:

ошибка — это возможность улучшить ваше понимание системы.

Если вам понравился этот пост и вы хотите похлопать меня по плечу по-дружески, вы можете «похлопать» и «подписаться». Спасибо!