## Сколько незаконченных Git-репозиториев лежит у вас на диске?
- где остались незакоммиченные изменения;
- какие коммиты ещё не отправлены;
- где забыты
- какие проекты изменились после последнего тега и готовы к новому релизу.
Инструмент проверяет не только текущую ветку, поэтому забытая работа в локальной feature-ветке тоже попадёт в список.
После установки достаточно запустить:
Есть фильтры, fuzzy-поиск, JSON-вывод, открытие проекта в редакторе и массовый
Полезная утилита для разработчиков, у которых папка
GitHub:
https://github.com/yetidevworks/drydock
drydock показывает их все в одном терминальном интерфейсе:- где остались незакоммиченные изменения;
- какие коммиты ещё не отправлены;
- где забыты
stash, конфликт или незавершённый rebase;- какие проекты изменились после последнего тега и готовы к новому релизу.
Инструмент проверяет не только текущую ветку, поэтому забытая работа в локальной feature-ветке тоже попадёт в список.
brew install yetidevworks/drydock/drydock
# или
cargo install drydock
После установки достаточно запустить:
drydock
Есть фильтры, fuzzy-поиск, JSON-вывод, открытие проекта в редакторе и массовый
fetch. Состояние репозиториев обновляется автоматически через файловый watcher.drydock написан на Rust с использованием Ratatui и работает на macOS и Linux.Полезная утилита для разработчиков, у которых папка
Projects давно превратилась в кладбище почти законченных идей.GitHub:
https://github.com/yetidevworks/drydock
🔥9❤3🥱3🥰2
🔥 Одна строка в конфиге ускорила production-ответ с 126–230 мс до менее чем 9 мс
Paweł Urbanek собрал очень практичный гайд по профилированию Rust, где оптимизации идут не по принципу «что интереснее», а по реальной отдаче.
Из кейсов:
Три последовательных HTTP-вызова →
Неправильно настроенный Brotli в
Ещё жёстче кейс с
И отдельная классика Tokio: unbounded channel молча накопил 73 сообщения, потому что consumer не успевал. Никакой ошибки, просто медленное движение к OOM.
Полезный порядок из гайда:
сначала SQL и HTTP, потом locks и channels, и только после этого CPU profiling.
Потому что один лишний поход в базу обычно стоит дороже, чем сотни мелких оптимизаций внутри hot loop.
🔗 https://hotpath.rs/blog/profiling-rust-guide
#Rust #Performance #Profiling #Tokio #Backend
Paweł Urbanek собрал очень практичный гайд по профилированию Rust, где оптимизации идут не по принципу «что интереснее», а по реальной отдаче.
Из кейсов:
N+1 SQL → 21 запрос превратили в один JOIN, функция ускорилась со 104 до 70 мкс.Три последовательных HTTP-вызова →
tokio::try_join!, итоговое время почти вдвое меньше.Неправильно настроенный Brotli в
maplibre/martin → скорость была всего 27,9 KB/s. Одна правка конфига дала примерно 57x ускорение, а latency упала до <9 мс.Ещё жёстче кейс с
write lock, который держали на всём HTTP round trip. После переноса блокировки P95 для читателей рухнул с 1,11 секунды до 9,42 мкс.И отдельная классика Tokio: unbounded channel молча накопил 73 сообщения, потому что consumer не успевал. Никакой ошибки, просто медленное движение к OOM.
Полезный порядок из гайда:
сначала SQL и HTTP, потом locks и channels, и только после этого CPU profiling.
Потому что один лишний поход в базу обычно стоит дороже, чем сотни мелких оптимизаций внутри hot loop.
🔗 https://hotpath.rs/blog/profiling-rust-guide
#Rust #Performance #Profiling #Tokio #Backend
👍20🔥12😁7❤4🤔1