Попробуйте использовать поменьше скобок (и не растягивать чрезмерно предложения), потому что выражение мыслей таким образом (как и наличие большого количества воды в тексте), не способствует, а как раз наоборот препятствует, её усвоению, что в конечном итоге сказывается на восприятии статьи (оставляя впечатление сумбурности), потому что наличие скобок (в первую очередь) зачастую воспринимается как перескакивание мысли в и без того не сильно структурированном тексте (тут бы могли помочь списки, а их, к сожалению, нет), но все равно спасибо за статью.
Значит у вас просто нет такой потребности. Мне тоже мало что из представленного нравится. В идеале хотелось бы, даже не знаю как назвать, context aware file manager :) То есть штуку, которая бы индексировала, связывала и структурировала файлы на диске по их содержимому. С поиском, тэгами и представлениями (workspace). Потому что markdown - это малая часть. Есть PDF доки и книги, есть примеры конфигов, есть куски проектов, есть софт. И всё это связано. А где подправить MD я и так найду.
У всех языков свои преимущества и недостатки. Ахиллесова пята Python в том, что приложения на нем трудно деплоить, потому что язык разрабатывался в первую очередь для инженеров. Для Go - это просто собрать бинарник. Для Java - скачать и распаковать JDK. А вот деплоить Python без контейнеров - это больно. Начиная с того, что официальных portable сборок под Linux просто не существует и заканчивая плясками вокруг virtualenv и версией glibc. А деплой в контейнеры это уже другой уровень сложности и архитектуры окружения.
Второй глобальный недостаток Python для меня - это его однопоточность. С приходом ASGI и FastAPI это уже менее актуально. Но если брать классику WSGI/Django, то Java Web приложения скейлятся по потокам, а WSGI - по процессам. Это значит что если приложение хочет считать/хранить хоть какие-то метрики (то есть shared state), то нужен как минимум Redis или просто база данных. Для условного сервиса это часто лишний и ненужный уровень сложности + лишняя зависимость.
Поэтому Python имеет место быть, и для ML вряд ли его кто-то заменит в обозримом будущем, но для Web, Java/Kotlin на чем-нибудь легком типа Micronaut/Helidon или Golang будут как минимум не хуже.
Если сравнивать языки, то в комплексе: решаемые задачи, библиотеки, сложность написания vs сложность чтения кода, быстродействие, комьюнити, безопасность, сборка и развертывание, качество и доступность инструментов разработки и прочее. А не где словарик короче инициализируется.
вы намеренно решили деградировать (примитизировали) свою систему дел, вместо того, чтобы её сделать лучше и оптимальнее
Я бы предпочел использовать термин минимализм, но по сути верно. Я оптимизировал систему под то количество времени, которое на данный момент готов уделять на её поддержку.
Чтобы не вставлять имхо после каждого предложения, сразу напишу, что описываю исключительно персональный опыт. Он, судя по всему, существенно отличается от вашего. Это в порядке вещей.
Система создаётся, чтобы решать какие-то проблемы. Возможно этими кастомными вьхами вы не решали никаких проблем. Поэтому они вам оказались по итогу не нужны.
Я не использовал плагин Tasks. Я написал собственный урезанный вариант вариант на базе Dataview (Tasks основан на нём же, если что), без повторяющихся задач и прочего ненужного. Причину вы озвучили в посте. В Tasks нет группировки по типам задач. А у меня была - и по типам задач, и по проектам. В графиках можно было посмотреть статистику выполненных задач - ожидалось, что это придаёт мотивации, но нет. Плюс, progress bar для проектов - тоже мимо.
В чём были недостатки старой системы из-за чего я от неё отказался:
Напряжно поддерживать тэги. При этом практически все они - не нужны.
Проще не иметь приоритета, потому что я и так знаю, что вот эта задача важная, а вот эта не очень. И если вдобавок приоритет устанавливается сверху, то завтра он может поменяться просто за одну минуту. Неважное станет важным и наоборот. В блокноте я просто перемещаю то что нужно вверх списка один хоткеем - всё. Контекст работы на день готов.
Проще не иметь категории, потому что я и так помню что к чему относится. Если нужна группировка, то я просто создаю отдельный файл или секцию.
Проще не ставить дедлайнов. Если я работаю на дядю, то уже нахожусь в контексте и знаю какую задачу надо закончить сегодня, какую до конца недели или месяца. Для этого есть багтрекеры, митинги и прочее. Если работаю на себя, то я не Илон Маск с миллионом задач на контроле, и тоже знаю с кём и о чём договорился. В целом даты вещь достаточно гибкая и намного более простой способ с ними работать это уделять определенное кол-во времени в неделю, а не медитировать каждый день на дедлайн в календаре.
Стремление ставить задачу на жёстко запланированную дату (которое пропагандируют примерно все тулзы) невероятно мешает. Оно по сути хорошо подходит разного рода менеджерам, у которых всегда чётко распланированный день, занятый митингами или созвонами. Для инженера это такое себе. Я могу напланировать кучу всего на день и потом бац, и несколько часов устранять последствия аварии, после чего у меня не останется энергии и я заработаю дебафф тем, что буду переносить таски на следующий день.
Если я в потоке, то мне вообще лень формулировать что-либо, потому что это отвлекает. Я могу запилить небольшой проект за день, с десятками задач не отвлекаясь вообще ни на что, и идти потом в TODO и описывать все это - просто лишняя трата времени.
Если обобщить все сказанное, от TODO мне нужны свобода и минимальные хинты для выбора маршрута, а не надсмотрщик с плеткой и гиперконтроль. Текстовый документ, как вы заметили, для этого походит лучше, потому что энергия затрачиваемая на поддержку инструмента в конечном итоге подпитывает прокрастинацию.
Вспомнилось, что у меня тоже была система управления задачами на базе Обсидиан. Тоже с эмодзи и развесистыми тэгами. Плюс, я еще через Dataview кастомные вьюхи делал и через Charts графики строил, типа кармы. Хватило меньше чем на год. Ну то есть, когда ты такую систему строишь, продумываешь и в итоге реализуешь, то испытываешь большое воодушевление. Это примерно как pet проект работает.
Но когда начинаешь всем этим реально пользоваться, то на дистанции в какие-то моменты у тебя становится очень мало энергии, которую высасывают другие задачи, и поддерживать всё это великолепие, где все разложено по полочкам и приятно щекочет перфекционизм, становится настолько влом, что мне лень было даже открывать Обсидиан. Может это только особенность такая, то для себя сделал вывод, что система должна быть максимально примитивной. На поддержку которой не тратишь примерно никакого времени. И чтобы приложение меньше чем за пару секунд открылось. И чтобы какой-бы бардак ты не навел, его можно было за 5 минут убрать.
Мне фитнес-браслет зашел для той же цели. В нем есть список таймеров: 1, 3, 5, 10, 15, 30, 60 минут. Ставится парой тапов, плюс вибрацию никак не пропустишь. Легко поставить на паузу, если отвлекли. По сути всего один девайс и для работы, и для тренировок, и для дневного сна, и для приготовления пищи. Очень удобно. Если нужно поработать, например, 25 минут, выбираю 15 + 10. Через 15 минут, после того как уже вкатился в задачу, я могу решить поработать подольше или поменьше.
Попробуйте использовать поменьше скобок (и не растягивать чрезмерно предложения), потому что выражение мыслей таким образом (как и наличие большого количества воды в тексте), не способствует, а как раз наоборот препятствует, её усвоению, что в конечном итоге сказывается на восприятии статьи (оставляя впечатление сумбурности), потому что наличие скобок (в первую очередь) зачастую воспринимается как перескакивание мысли в и без того не сильно структурированном тексте (тут бы могли помочь списки, а их, к сожалению, нет), но все равно спасибо за статью.
Значит у вас просто нет такой потребности. Мне тоже мало что из представленного нравится. В идеале хотелось бы, даже не знаю как назвать, context aware file manager :) То есть штуку, которая бы индексировала, связывала и структурировала файлы на диске по их содержимому. С поиском, тэгами и представлениями (workspace). Потому что markdown - это малая часть. Есть PDF доки и книги, есть примеры конфигов, есть куски проектов, есть софт. И всё это связано. А где подправить MD я и так найду.
Опять же от задачи зависит. Питон = клей вокруг C/C++ либ. Чем тоньше слой, тем быстрее :) Если в задаче просто ввод/вывод, то вполне шустро работает.
У всех языков свои преимущества и недостатки. Ахиллесова пята Python в том, что приложения на нем трудно деплоить, потому что язык разрабатывался в первую очередь для инженеров. Для Go - это просто собрать бинарник. Для Java - скачать и распаковать JDK. А вот деплоить Python без контейнеров - это больно. Начиная с того, что официальных portable сборок под Linux просто не существует и заканчивая плясками вокруг virtualenv и версией glibc. А деплой в контейнеры это уже другой уровень сложности и архитектуры окружения.
Второй глобальный недостаток Python для меня - это его однопоточность. С приходом ASGI и FastAPI это уже менее актуально. Но если брать классику WSGI/Django, то Java Web приложения скейлятся по потокам, а WSGI - по процессам. Это значит что если приложение хочет считать/хранить хоть какие-то метрики (то есть shared state), то нужен как минимум Redis или просто база данных. Для условного сервиса это часто лишний и ненужный уровень сложности + лишняя зависимость.
Поэтому Python имеет место быть, и для ML вряд ли его кто-то заменит в обозримом будущем, но для Web, Java/Kotlin на чем-нибудь легком типа Micronaut/Helidon или Golang будут как минимум не хуже.
Если сравнивать языки, то в комплексе: решаемые задачи, библиотеки, сложность написания vs сложность чтения кода, быстродействие, комьюнити, безопасность, сборка и развертывание, качество и доступность инструментов разработки и прочее. А не где словарик короче инициализируется.
Не смотрели в сторону fzf? Он умеет в автокомплит SSH из коробки.
Я бы предпочел использовать термин минимализм, но по сути верно. Я оптимизировал систему под то количество времени, которое на данный момент готов уделять на её поддержку.
Чтобы не вставлять имхо после каждого предложения, сразу напишу, что описываю исключительно персональный опыт. Он, судя по всему, существенно отличается от вашего. Это в порядке вещей.
Я не использовал плагин Tasks. Я написал собственный урезанный вариант вариант на базе Dataview (Tasks основан на нём же, если что), без повторяющихся задач и прочего ненужного. Причину вы озвучили в посте. В Tasks нет группировки по типам задач. А у меня была - и по типам задач, и по проектам. В графиках можно было посмотреть статистику выполненных задач - ожидалось, что это придаёт мотивации, но нет. Плюс, progress bar для проектов - тоже мимо.
В чём были недостатки старой системы из-за чего я от неё отказался:
Напряжно поддерживать тэги. При этом практически все они - не нужны.
Проще не иметь приоритета, потому что я и так знаю, что вот эта задача важная, а вот эта не очень. И если вдобавок приоритет устанавливается сверху, то завтра он может поменяться просто за одну минуту. Неважное станет важным и наоборот. В блокноте я просто перемещаю то что нужно вверх списка один хоткеем - всё. Контекст работы на день готов.
Проще не иметь категории, потому что я и так помню что к чему относится. Если нужна группировка, то я просто создаю отдельный файл или секцию.
Проще не ставить дедлайнов. Если я работаю на дядю, то уже нахожусь в контексте и знаю какую задачу надо закончить сегодня, какую до конца недели или месяца. Для этого есть багтрекеры, митинги и прочее. Если работаю на себя, то я не Илон Маск с миллионом задач на контроле, и тоже знаю с кём и о чём договорился. В целом даты вещь достаточно гибкая и намного более простой способ с ними работать это уделять определенное кол-во времени в неделю, а не медитировать каждый день на дедлайн в календаре.
Стремление ставить задачу на жёстко запланированную дату (которое пропагандируют примерно все тулзы) невероятно мешает. Оно по сути хорошо подходит разного рода менеджерам, у которых всегда чётко распланированный день, занятый митингами или созвонами. Для инженера это такое себе. Я могу напланировать кучу всего на день и потом бац, и несколько часов устранять последствия аварии, после чего у меня не останется энергии и я заработаю дебафф тем, что буду переносить таски на следующий день.
Если я в потоке, то мне вообще лень формулировать что-либо, потому что это отвлекает. Я могу запилить небольшой проект за день, с десятками задач не отвлекаясь вообще ни на что, и идти потом в TODO и описывать все это - просто лишняя трата времени.
Если обобщить все сказанное, от TODO мне нужны свобода и минимальные хинты для выбора маршрута, а не надсмотрщик с плеткой и гиперконтроль. Текстовый документ, как вы заметили, для этого походит лучше, потому что энергия затрачиваемая на поддержку инструмента в конечном итоге подпитывает прокрастинацию.
Вспомнилось, что у меня тоже была система управления задачами на базе Обсидиан. Тоже с эмодзи и развесистыми тэгами. Плюс, я еще через Dataview кастомные вьюхи делал и через Charts графики строил, типа кармы. Хватило меньше чем на год. Ну то есть, когда ты такую систему строишь, продумываешь и в итоге реализуешь, то испытываешь большое воодушевление. Это примерно как pet проект работает.
Но когда начинаешь всем этим реально пользоваться, то на дистанции в какие-то моменты у тебя становится очень мало энергии, которую высасывают другие задачи, и поддерживать всё это великолепие, где все разложено по полочкам и приятно щекочет перфекционизм, становится настолько влом, что мне лень было даже открывать Обсидиан. Может это только особенность такая, то для себя сделал вывод, что система должна быть максимально примитивной. На поддержку которой не тратишь примерно никакого времени. И чтобы приложение меньше чем за пару секунд открылось. И чтобы какой-бы бардак ты не навел, его можно было за 5 минут убрать.
Мне фитнес-браслет зашел для той же цели. В нем есть список таймеров: 1, 3, 5, 10, 15, 30, 60 минут. Ставится парой тапов, плюс вибрацию никак не пропустишь. Легко поставить на паузу, если отвлекли. По сути всего один девайс и для работы, и для тренировок, и для дневного сна, и для приготовления пищи. Очень удобно. Если нужно поработать, например, 25 минут, выбираю 15 + 10. Через 15 минут, после того как уже вкатился в задачу, я могу решить поработать подольше или поменьше.