Недавно у нас был пост-стенание о том, куда христианину податься, если слак забанил. Там прошло бурное и плодотворное обсуждение. В отдельном посте расскажем о нашем выборе. Он, вероятно, своеобразный, но таковы обстоятельства. Пока тестируем.

В подкасте я упоминал, что мы по привычке пользуемся связкой Jira и Confluence. Но у ребят стало всё сильно сложнее с self-hosted — вроде бы, они вообще его убрали. Ну и платить им тоже проблемно.

Оно пока работает и кушать не просит, но в фоне мы начали смотреть на альтернативы. Расскажите, пожалуйста, чем вы пользуетесь на практике для ведения задач проектов и документации? Чем довольны, чем нет?

#tools #devfm

Инструмент для анализа узких мест базы данных

В статье из предыдущего поста автор приводит некоторые вспомогательные запросы для анализа порядка столбцов в таблице. Могу порекомендовать удобную тулзу postgres_dba, которая проведет проведет анализ и выдаст рекомендации, где и сколько потенциально можно сэкономить.

Также с помощью с неё можно посмотреть: коннекты, медленные запросы, неиспользуемые индексы, битые индексы, различные статистики и ещё всякое разное.

Мы обновили подборку всех наших постов по базам данных. Там много интересного.

UPD: в комментарии рассказали о еще одном полезном инструменте.

#tools #database

Micro — консольный редактор с человеческим лицом

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

Для этих целей давно использую micro – легковесный редактор с поддержкой мышки, а главное – с привычными горячими клавишами.

В нашем бесплатном курсе cli-for-dev есть урок про редакторы nano, mcedit, gedit, vim. В центре внимания горячие клавиши. Скоро допишем туда про micro.

P.S. Vim`оводам пост, конечно, будет неактуален 😄

#tools

Снова о необходимости архитектурных схем

Продолжим пост об архитектурных схемах с более практической стороны.

– Как-то так повелось, что мы используем C4 model. Не нагромождённая и достаточно лаконичная. Если вдруг кому-то кажется, что C4 – это какая-то новомодная модель, спешу разочаровать. Придумана она была почти 20 лет назад.

– C4 model не предусматривает никакой описательной части, поэтому ко всем архитектурным схемам у нас имеется тезисное описание всех компонентов, изображённых на схеме.

– C4 несложная, но глаз может замылиться, а всё ли сделано правильно? На этот случай на официальном сайте есть чеклист (там же можно скачать pdf), по которому можно быстро проверить вашу схему на соответствие правилам и адекватность.

– Хотя я очень люблю делать схемы в визуальных редакторах, но понимаю, что реюзабельность такого творчества страдает, поэтому правильно готовить такие схемы в виде кода. Хорошим решением будет Structurizr. Опенсорсная селфхостед штуковина. Помимо самих схем, там же можно документировать своё решение.

– По моему опыту очень полезной может оказаться Deployment диаграмма. Её можно немного извратить, отойти от канонов и получить примерно такое изображение. Особенно удобно, когда существует целый зоопарк самых разнообразных сервисов. Все они в разных закрытых сетевых контурах, с разными командами поддержки. Кто-то должен предоставить вам кубер, кто-то базы, кто-то s3. Что-то будет в Harvester, что-то в Proxmox. Такая диаграмма поможет разобраться во всём этом и как-то структурировать. А новый девопс на вашем проекте скажет за такое большое человеческое спасибо.

#devfm #systemdesign #tools

Ведение дел – мой опыт

Часто начинающие тим лиды имеют сложности с тайм-менеджментом. У них появляются новые зоны ответственности, новые задачи, интерапты, о которых они раньше и не слышали, больше общения с людьми. В общем, совершенно новый опыт.

Что уж говорить, и у опытных ребят бывают сложности с тайм-менеджментом, когда наваливается куча всякого.

И мы на 121-встречах обсуждаем эти проблемы, думаем как решить, потому что ситуации в целом типовые, а вот решения могут быть разные.

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

Полезно всем, у кого есть запрос на понятное и упорядоченное ведение своих дел.

Лайки, конечно же, приветствуются.
#devfm #edu #tools

Некоторое время назад прочитал у Николая Хитрова пост о том, как он затащил к себе на проект gitlint — инструмент для валидации commit messages.

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

Ребята внедрили себе gitlint и уже несколько месяцев полноценно им пользуются. По отзывам разработчиков: кому-то понравилось, что теперь коммиты нужно писать более дисциплинированно, кто-то и так их качественно писал, поэтому и не заметил разницы. Кто-то, конечно, воняет до сих пор, но на них не отвлекаемся :)

Мне же приятно, что ченджлог и история коммитов теперь выглядит стройненько и единообразно.

За вдохновением по правилам написания коммитов загляните сюда.

Чтобы всем этим добром легче пользоваться, существуют всевозможные плагины для вашей IDE.

Вдогонку посмотрите еще на comimitizen.

Не на каждом проекте нужны такие штуки, но может именно на вашем пригодится.
#devfm #tools

Автоматизируй автоматизируемое

Это пост для исключительно для маководов.

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

Начну с банального: слёзы текут, когда вижу как кто-то неуклюже ищет нужное ему окно. Ой, это браузер, ой, это почта, блин, это IDE, фух, вот же он — телеграмчик!

Первое, что у меня настроено в Raycast — это хоткеи абсолютно на все программы, которыми я постоянно пользуюсь: Option + M — почта, Option + T — телеграм, option + B — браузер, и т.д.

Штука рекомендуема к использованию абсолютно всем. Периодически буду делать посты, рассказывая, что ещё интересного с помощью неё делаю.

Также стоит обратить внимание на плагины для Raycast — они предоставляют какое-то нереальное количество возможностей. Переводчик, управление зумом, очистка текста в clipboard от спец символов, конвертер времени из юникс формата — всё через плагины.
#devfm #tools

Как я использую папки в Телеграм для удобства

Меня несколько раз спрашивали, как я живу с сотней активных чатов и десятком групповых. Сегодня необычное — о нашем опыте применения папок в ТГ для асинхронной коммуникации по работе. Как работать с огромным количеством чатов с длительным сроком жизни? Как удобно организовать чтение каналов, если у вас сотня каналов к прочтению?

#devfm #edu #tools

Обзор способов защиты контейнеров Docker

Докеры мы любим, а думать о безопасности докеров — не всегда.

Неплохая обзорная статья о том, что вы можете сделать для повышения безопасности, чтобы не попасть впросак :)

Автор начинает с актуальности в виде известных инцидентов за 2024 год и, в целом, видов угроз для контейнеров.

Итак, переходим к делу:
🔹 Ограничивайте привилегии контейнеров — по умолчанию они могут запускаться с избыточными правами, что создает новые вектора для атак. Отключайте ненужные привилегии.
🔹 Запускайте rootless-контейнеры — пусть они работают от имени обычного пользователя, а не от root'а.
🔹 Настраивайте сетевую изоляцию — не давайте контейнерам бесконтрольно общаться друг с другом и с внешним миром. Чётко определяйте, кто с кем может взаимодействовать.
🔹 Используйте специальные инструменты — AppArmor, Seccomp и SELinux, они помогут ограничивать системные вызовы и предотвращать несанкционированный доступ к критическим ресурсам.
🔹 Сканируйте образы на уязвимости — Trivy, Docker Scout и аналогичные инструменты помогут обнаружить проблемные зависимости ещё на этапе сборки. Встраивайте эти инструменты в свой CI/CD.
🔹 И, самое базовое, что может делать каждый разработчик — минимизируйте образы, убирайте лишние зависимости, не тяните за собой ненужные файлы, следите за обновлениями базовых образов, запускайте контейнеры от не привилегированных пользователей.

#tools #docker

Таки посмотрите на uv

Мы уже писали о быстром пакетном менеджере для Python — uv. Кто-то уже успел его пощупать? Я затащил его в несколько своих проектов — полёт нормальный. В продакшн хотели затащить, но так и не нашли весомых причин.

На днях вышла статья — A year of uv: pros, cons, and should you migrate. Автор в восторге от uv, и когда постарался упомянуть минусы, то даже от них скорее в восторге. В итоге текст — отличный вариант вдохновиться на использование этого инструмента. А если хотите узнать про подводные камни — залетайте в комменты, там автору уже насували.

#tools #python

Markwhen — для построения роадмапов

Обычно построением роадмапов занимаются руководители проектов, но иногда это нужно и тимлидам или другим техническим руководителям.

Хочу поделиться гиковским опенсорсным инструментом — Markwhen.

Markwhen позволяет строить роадмапы с использованием синтаксиса Markdown и хранить их в git. Из минусов обнаружил невозможность выставлять зависимости между колбасками.
Вот тут можно потыкать инструмент, посмотреть на его возможности, синтаксис и способы визуализации. А тут документация.

Также у ребят есть всевозможные расширения в том числе для Obsidian и VSCode.

#tools

Diagrams

Нравится мне python, а если с его помощью ещё и архитектурные диаграммы рисовать — вообще красота. Поэтому принес ещё один инструмент, позволяющий кодом на питоне создавать архитектурные схемы. В примерах можно посмотреть как это выглядит: тут и тут.

Затащить в полноценное использование командами такой инструмент у меня, конечно, не получится (да и смысла большого нет), но развернуть локально и потыкать интересно. На практике мы используем Structurizer. А ранее у нас был пост, зачем мы документируем архитектуру.

#tools

fd – удобная альтернатива find

Если используете на практике find, то посмотрите на fd.

Работает быстрее, флаги более лаконичные и поведение по умолчанию разумнее. Вот пару примеров:
🔹 fd сам ищет файлы в текущем каталоге (не нужно писать .) и не требует флага -name

fd txt # Найдет все файлы с "txt" в названии

В find пришлось бы писать:

find . -name "*.txt"

🔹по умолчанию игнорирует скрытые файлы. А еще игнорирует то, что у вас лежит в .gitignore. Очень удобно, избавляет от кучи лишних совпадений. В find же нужно указывать

-not -path ‘*/path/*’

🔹можно делать цветной, более наглядный вывод

🔹написан на Rust, ну, сами понимаете – всё работает быстро-быстро 🙂

В ридми у ребят ещё много примеров.

#tools