[О блоге]
[наверх]
[пред]
[2025-06-10 11:37:25+03:00]
[238c110ef3d7c98ee4d228f1325bef7c46178811]
Темы: [apple][git][python][systemd][zsh]
"Гайд" по настройке рабочего окружения: Linux, VScode, Python
https://habr.com/ru/companies/timeweb/articles/916040/
Эх, бомбит меня от современных норм рабочего окружения разработчика.
Но что взять с людей, которые сейчас хотят заниматься Python?
* Главный снимок экрана отмечен надписью "Космический корабль".
И что в этом хорошего? Тьма места занята информацией, которая явно не
нужна постоянно и оперативно. На два вертикальных split места уже
точно не хватит. Причём на снимке с "минимализмом", видно что места на
небольшом экране хватило бы
* Автор пишет про Unix-философию, типа топит за неё, каждой задаче свой
инструмент, но... причём тут тогда IDE?
* Показывает подставку для говняного ноутбука, где просто отвратительная
клавиатура. Автор прав, что всё должно начинаться с физического мира,
но картинка показала эталон убожества
* "вместо мыши у меня тачпад. В таком сетапе экранного места мало,
поэтому я экономлю на всём, и неиспользуемого пространства почти нет".
Кхм, это в его то снимках экрана с XFCE и IDE нет неиспользуемого
пространства?
* XFCE: "Оно легковесное!". "Минимализм и лаконичность". Ну ну. Если
только сравнивать с GNOME/KDE/similar
* "Можно выпилить шапки окон! Вы никогда не задумывались, что они
бесполезны?" -- а вот это одобряю и поддерживаю. Вот только наличие
вертикальной панели запуска -- пустая трата места всё равно
* Желание иметь запускатор программок и быстро переключаться на них тоже
одобряю. Даже быстренько иметь возможность в калькуляторе что-то
посчитать -- это хорошо. Не понимаю, правда, почему это всё в GUI
обмазано и тяжеловесными программами с плагинами на Python, но лучше
чем ничего
* "У нас, линуксоидов, есть репозитории, откуда мы ставим наш софт. Но
иногда там может чего-то не быть!". "Если софта нет в официальном
репозитории дистрибутива, можно подключить сторонний репозиторий".
"Можно запустить через Docker". "Можно превратить WebUI в приложение,
как в предыдущем пункте". "Но последний оплот — это Flatpak / AppImage
/ Snap". "Можно посмотреть рецепт, как собрать из исходников самому".
Варианта просто самостоятельно собрать -- не предлагает. Хотя
соглашусь, что для многий современный хипстерский софт, особенно с
web-мордами, о которых много упоминает автор, чёрт соберёшь
самостоятельно. Но а стоит ли трата сил на него? Ах да, почти все
варианты установок намекают на скачивание непойми кем собранного бинаря
* "Многие это, наверно, знают, но когда я впервые об этом узнал, это
перевернуло игру" и дальше упоминание Ctrl+A, Ctrl+E, "open"... и это
всё!?!?!? Причём Home/End вроде бы как тоже со времён DOS перемещали в
начало/конец. Ах да, у автора же железо от Apple, а значит там кнопок
раза в два меньше
* Автор любит fish. Считаю что лучше уж fish, да, чем bash. Автор
заявляет, что bash можно до вменяемого состояния настроить -- я даже
близко не мог бы, ибо он мало что умеет. "Из минусов fish: несовместим
с синтаксисом bash" -- какой же это минус?
* Строка ввода настроена на использование многострочного приглашения.
Как не понимал, так и не понимаю этого. Особенно (!!!) если хочет
экономить место на небольшом экране. У коллег видел многострочные
prompt-ы, но у них хотя бы здоровенные мониторы с маленьким
(для меня) шрифтом. Но никогда не встречал даже намёка на пользу от
них. Кто-то вроде мне говорил, что это для лучшего поиска разделителя
между запускаемыми командами. Это мог бы быть хороший аргумент, но
вроде бы хорошая цветовая подсветка строки приглашения достаточна
* Упоминает Zoxide и "z dir" команду. Я тоже когда-то использовал что-то
подобное (вроде называлось по другому, но команда тоже была "z"). С
применением алиасов на директории, autopushd, F-клавиш для popd и
"cd ..", даже не вспоминаю про "z", хотя тоже думал как без него можно
бы было прожить. Но уж лучше "z" использовать, чем вообще ничего и
вводить тьму cd, cd, ls, cd, cd, ls...
* direnv -- лучше чем ничего, но я ярый противник оного, ибо 99%
use-case-ов можно гораздо более простым autoenv-ом покрыть, а не
колоссальным framework-ом (37a5f6e79cff402f892ba9b0f9d5aa52890b7e8f,
cc8983dbab9a15576c2cf6a0b0c88c9dd1c0c225,
9d4cf2a2b3af496ac3e719dd2c6ee73c4761379e). Но, не знаю есть ли аналоги
autoenv для fish, но монстра direnv бы никогда не использовал
* trash-cli. Никогда от коллег не слышал ни о чём подобном, как и о том,
что кто-то не настолько аккуратен с rm/backup чтобы боятся удалить
лишнего. Но я не вижу смысла в подобных утилитах: если иметь ZFS
snapshot-ы, то из них можно достать старые файлы. Но да, на GNU/Linux
с ZFS возможно всё ещё не очень
* xh -- то ли я не настолько много разрабатывал для REST/HTTP, то ли
cURL с скриптами более чем хватало. Но xh/whatever не пробовал. Но
напрягает фраза автора "Для более основательных экспериментов,
разумеется, рекомендую что-то с GUI"
* jq -- когда-то (40cb8a257f73cc02ea67ad7d50d6a5064ccda81b) пользовался,
но перешёл на gojq и gjo. Сильно более простые и минималистичные
аналоги на Go. Думаю, что для 99% людей, их функционала будет
достаточно
* про команду thefuck слышал, но всерьёз коллеги никогда не воспринимали
её. Как и я. Аккуратнее вводить? Пользоваться функциями редактирования
строк/истории в zsh (хз как в fish с этим)? Писать скрипты вспомогательные,
если с чем то чаще ошибаешься? Я боюсь, что thefuck может только
способствовать неаккуратной работе, как и trash-cli
* obsidian -- много раз про него слышал и читал, так как смотрел в
сторону темы zettelkästen. GUI? Спасибо, не надо, без вменяемого
редактора то. Но, лучше чем ничего, лучше чем вообще не вести никакой
БД знаний
* syncthing -- одобряю смотрение в сторону self-hosted решений. Но, судя
по тексту, автор вынужден был посмотреть в эту сторону, потому что
карточки к оплате какого-то проприетарного сервиса перестали работать.
Сам syncthing не использовал, ибо первая попытка его собрать
обломалась на том, что он отказался собираться с Go, где изменена
какая-то TLS-related структура данных. Желание попробовать -- пропало.
Хотя там делов то на минуту наверное было. Ну а сейчас другая
серьёзная причина слать их в жопу: они спонсировали нацистов,
хвалились этим
* fzf -- одобряю
* gitg -- судя по снимку экрана, можно было бы всё это сделать скриптом
для терминала с использованием fzf. Нет, не понять мне как тут и чем
GUI софт может помогать
* meld -- ничего не могу прокомментировать. У самого было временами
желание использовать что-то помощнее родных vimdiff/git средств для
просмотра изменений. Но так ничего и не пробовал ещё. Само собой это
не мог бы быть meld, ибо GUI, к тому же требующий Python
* redshift -- есть коллеги, которые тоже считают что без него невозможно
им работать. Я не пробовал. Ибо я просто не понимаю проблемы. Не
говорю что её нет, но вот вообще никогда цвет/яркость меня не парили.
Может быть, потому что я никогда не работаю во мраке или темноте?
Всегда есть внешний дополнительный свет рядом с монитором?
* использовать сторонний сервис для нотификаций? ntfy.sh. Звучит как
лютая жесть. Что, совсем современные люди не могут без сторонних
сервисов на любой чих? И ведь это всё на фоне того, что многий софт
можно через docker/whatever ставить, типа вообще парой кликов. Но ok,
возможно я не прав, ибо возможно с мобильными устройствами такая жопа,
что с self-host решениями ничего не выйдет
* автор радуется тому, что дожил до момента, когда вместо Makefile
используется что-то другое. Я же рад моменту, что не дожил, будучи
бывшим Python-разрабом, до применения just, tox, nox, uv и прочего. Мы
оба рады :-)
* для резервных копий автор упоминает rsync и rclone. Одобряю сам факт
того, что человек об этом беспокоится. Конечно, после ZFS, все эти
rsync выглядят устаревшей дикостью, но это ж GNU/Linux. rclone кстати
и собирал и проверял с чем-то работоспособность: действительно вроде
бы нормально работал, если кому-то нужны облака
* забота об очистке мусора, где у автора как-то 200 гигов было
освобождено -- одобряю. Многие современные пользователи/разработчики
вообще не знают что и сколько у них примерно места занимает на диске
* про IDE ничего не могу сказать. Вижу, что есть много инструментов
визуализации паршивого/запутанного кода. Лучше бы заняться
переписыванием подобного кода, а то без бутылки, то есть IDE, не
разберёшь. Даже сам автор пишет: "Что тут вызовется? А хрен его знает,
без рантайма и не скажешь!". То есть, IDE это такой батискаф,
позволяющий в куче говн плавать. Плагины типа highlight -- всё и в Vim
есть, как и заметки с mark-ами. Аналогично и про fold-ы.
* ipython/ipdd -- помню что я какие-то простые, но существенно
улучшающие жизнь вещи делал для облагораживания штатного REPL Python.
Как минимум, многострочный код через внешний редактор, вызванный из
readline (libedit?) можно было вводить. Коллеги использовали и ipython
и ipdf, но мне запомнилось, что я почти был на уровне подошёл по
удобству с их громоздкими решениями. Но вот реально уже забыл всё что
делал. Уверен, что к лучшему, как же не хочу я больше видеть Python
* одобряю желание автора использовать структурированное журналирование.
Про конкретные предложенные им библиотеки ничего не могу сказать -- не
видел. Как-то так выходило, что всегда были все самописные решения
С одной стороны, одобряю стремление автора работать эффективно, не
тратить время на рутину и ускорять часто выполняемые действия. С другой:
сварливо ворчу касательно конкретного выбора инструментов. Но точно не
могу понять желание так много использовать GUI, да ещё и IDE. И даже в
этой статье не видно никаких крутых и полезных фич IDE, ну кроме как
из коробки визуализация говн, что не особо тянет считать плюсом. Ну и
его XFCE+VSC идут вразрез со стремлением выжать максимума пользы из
относительно небольшого пространства на экране. Но даже таких людей не
много -- преобладающее большинство на голой Ubuntu (где уже даже Git не
работал из коробки (5a5f294205d75ea306233e056a5fe1da006a2baf), не говоря
про терминал (70593bcac3eb3323307ddbe158fc829438bacd08)) пытается работать.
[оставить комментарий]