[О блоге] [наверх] [пред] [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)) пытается работать.

    [оставить комментарий]