Comments 18
В недостатки нужно еще добавить, что такое имя файла будет нечитабельно во многих файл–менеджерах (будет свернуто).
Ну и лично мне удобнее пользоваться мета-информацией.
Ну и лично мне удобнее пользоваться мета-информацией.
+2
1. Идея в том, что файл-менеджерами пользоваться в таком случае просто нет необходимости. В OS X все видно в окне Spotlight или, например, Alfred:
2. А почему именно удобней пользоваться мета?
2. А почему именно удобней пользоваться мета?
0
Потому что такие имена файлов мне ни к чему, файлами еще приходится делиться с окружающими.
Да и мета отлично ищется spotlight-ом и иным софтом.
Да и мета отлично ищется spotlight-ом и иным софтом.
+1
вот уже в вашем примере видно, что если параметров будет больше, ну еще парочку добавить, то они и в строку альфреда не влезут. Либо надо добавлять их в конце файла, а не в начале. А еще бывают такие веселые вещи, как максимальная длина пути. Или максимальная длина имени файла, когда начинает пихать различные удобные для поиска вещи в название файла думаешь что это все глупость, и предел тебе не грозит, а потом приходиться идти на уступке, что приводит к общей бессмысленности всей этой затеи. К тому же в метаданные можно много чего записать. Как это делают те же браузеры в маке, например очень удобно искать файлы по тому откуда ты их скачал. ^_^
Да, метаданные не копируются на другие фс, да даже на флешку не перекинешь. Когда то давным давно было у меня светлое желание хранить метаданные в потоках ntfs. Но реальность оказалась уж больно жестокой.
Можно класть метаданные в отдельные файлы, и чтобы софт их считывал, но тоже не лучший вариант, потому что не факт что скопируя у тебя файл пользователь захватит этот файл. И вот тут начинаются уже более хитрые и сложные решения. :(
Да, метаданные не копируются на другие фс, да даже на флешку не перекинешь. Когда то давным давно было у меня светлое желание хранить метаданные в потоках ntfs. Но реальность оказалась уж больно жестокой.
Можно класть метаданные в отдельные файлы, и чтобы софт их считывал, но тоже не лучший вариант, потому что не факт что скопируя у тебя файл пользователь захватит этот файл. И вот тут начинаются уже более хитрые и сложные решения. :(
0
Практика показывает, что серьезных интерфейсных сложностей нет. Во-первых, параметров редко бывает много. Во-вторых, при поиске через Spotlight доступен предпросмотр. В-третьих, одним кликом открывается все найденное в Finder (там обычно лишь несколько позиций), где видно всю строку.
0
ну так если бы это были метаданные, то прямо в поиске по спотлайт можно было выбрать, без открытия в файндере. поскольку метаданные не забивили бы обзор, тот же файндер кстати тоже не резиновый, хотя окно пошире открыть, и столбец по максимуму расширить — это вариант, но в целом как то не то. А что делать с этим файлом и этой папкой в дропбоксе, на телефоне, если нужно что то найти? ;) поле с именем файла на телефонах не такое уж и широкое.
0
где видно всю строкуЗависит от того как настроен Finder. У меня вот он всегда в режиме Icon. И такое имя файла превратиться в непонятный набор символов.
Менять привычки весьма сложно.
Не вижу никакой выгоды от вашего метода.
Искать по метаданным удобнее, хоть spotlight-ом хоть сторонним софтом.
Способы синхронизировать файлы с метаданными существуют. И при этом не надо никак манипулировать с самими файлами.
Но если вы получаете профит от данного метода – это замечательно.
+1
хм, а не подскажете способы синхронизации файлов с метаданными? .ds_store копировать?
0
.ds_store – это лейоут папки, а не метаданные.
Метаданные синкаются btsync, rsync (с флагом -Е). По крайнее мере у меня синкались.
Хотя я в основном пользуюсь специализированным софтом и синкаю его базу.
Метаданные синкаются btsync, rsync (с флагом -Е). По крайнее мере у меня синкались.
Хотя я в основном пользуюсь специализированным софтом и синкаю его базу.
+1
ну в ds_store иногда часть метаданных пишется. Например комментарии spotlight'а :)
Про то что btsync синхронизует метаданные это интересно, не знал этого. касательно rsync'a честно говоря есть сомнение, если синхронизировать каталог например не с HFS.
А не поделитесь каким софтом, для каких целей и как именно пользуетесь, было бы интересно узнать.
Про то что btsync синхронизует метаданные это интересно, не знал этого. касательно rsync'a честно говоря есть сомнение, если синхронизировать каталог например не с HFS.
А не поделитесь каким софтом, для каких целей и как именно пользуетесь, было бы интересно узнать.
0
ну в ds_store иногда часть метаданных пишется. Например комментарии spotlight'а :)Честно говоря я не помню, но в любом случае этот файл имеет отношеное только к директории, не к файлам.
Про то что btsync синхронизует метаданные это интересно, не знал этого.Поройтесь у них на форуме, там есть отдельные топики, посвященные этому.
касательно rsync'a честно говоря есть сомнение, если синхронизировать каталог например не с HFSЯ не пробовал синхронизацию с «не HFS».
Ну, например, Dropbox это как–то решил (сомневаюсь, что они пользуются HFS).
И да, Dropbox (как минимум частично) и iCloud также синхронизируют метаданные.
В последнее время практически ничем не пользуюсь, достаточно родного spotlight.
Раньше активно пользовался HoudahSpot и Punakea, в основном для работы с книгами и фото.
Тут есть хоть и устаревший, но неплохой список приложений.
+1
Именуя файлы таким образом вы потратите больше времени чем при обычном поиске/повторном скачивании из интернета.
Если это текстовый/офисный документ тут все очень просто: стандартный локальный поисковик (они сейчас хорошие во всех ОС) или уже grep/find.
Если это медиаконтент — очевидно он будет лежать либо в Downloads, либо в какой-нибудь папке Videos/Movies/Music, причем с датой добавления, есть превьюшки, иногда даже вразумительные имена файлов (что не критично) обычно ищется за пару минут в самом худшем случае.
Если же это скрипт или код — советую использовать git + GitHub/Bitbucket/etc. никогда ничего не потеряется.
Это я молчу про проприетарные штуки как например теги в OSX и разные стандартные медиатеки. Мне кажется все эти проблемы с потерей файлов весьма надуманы и иллюзорны.
Что я упустил? Зачем истязать себя и тратить время?
Если это текстовый/офисный документ тут все очень просто: стандартный локальный поисковик (они сейчас хорошие во всех ОС) или уже grep/find.
Если это медиаконтент — очевидно он будет лежать либо в Downloads, либо в какой-нибудь папке Videos/Movies/Music, причем с датой добавления, есть превьюшки, иногда даже вразумительные имена файлов (что не критично) обычно ищется за пару минут в самом худшем случае.
Если же это скрипт или код — советую использовать git + GitHub/Bitbucket/etc. никогда ничего не потеряется.
Это я молчу про проприетарные штуки как например теги в OSX и разные стандартные медиатеки. Мне кажется все эти проблемы с потерей файлов весьма надуманы и иллюзорны.
Что я упустил? Зачем истязать себя и тратить время?
+6
1. Повторное скачивание из Интернета возможно, если вы знаете точно что вы ищите. А если вам просто нужны стоящие статьи по теме, которые когда-то попались на пути? Можно бесконечно раздувать список ReadLater, а можно просто отнести статью к определенной задаче и сохранить. Собственно, только такие вещи и надо сохранять. Ну, еще и те, что хочется иметь локально.
2. У меня много текстовых документов. Поиском по текстовому содержанию не удается обойтись. Но, вероятно, тут уже у кого как работа устроена.
3. Медиаконтент — в общем согласен. Я его вообще не храню. Бывает, правда, если хороший ролик, просто помечаю webloc-файл определенной эмоцией и сохраняю его. Потом приятно посмотреть что-то давнее, что зацепило.
4. Исходные коды — капля в море.
5. Про теги — в статье сказано.
6. Мне кажется, что главная сложность в непривычности. Это вообще не отнимает время. Файлы все равно именуются и размещаются где-то. Тут просто предлагается это делать системно.
2. У меня много текстовых документов. Поиском по текстовому содержанию не удается обойтись. Но, вероятно, тут уже у кого как работа устроена.
3. Медиаконтент — в общем согласен. Я его вообще не храню. Бывает, правда, если хороший ролик, просто помечаю webloc-файл определенной эмоцией и сохраняю его. Потом приятно посмотреть что-то давнее, что зацепило.
4. Исходные коды — капля в море.
5. Про теги — в статье сказано.
6. Мне кажется, что главная сложность в непривычности. Это вообще не отнимает время. Файлы все равно именуются и размещаются где-то. Тут просто предлагается это делать системно.
0
Любые файлы, даже названные вот так, надо время от времени пересматривать, что то убирать, что то добавлять, какие то категории поправлять, это будет постоянно происходить. В итоге на поддержание этого всего в актуальном состоянии времени будет уходить много. И все это покроется пылью, когда выяснится что найти все это в поисковике банально быстрее чем на локальной машине. Что приведет к тому что информацию вы сами же и перестанете сохранять. Или именовать, ну и так далее.
Да, любые системы это очень индивидуально, кому то очень удобно работать с Evernote, кто то как не пытается не может с ним работать.
Списки ReadLater бессмысленны если их не чистить, а прочитанное не переносить в какую то систему знаний. Поиск по тексту файла к сожалению не сравнится с тем как ищут поисковики, постоянно совершенствуясь, а также пользователи которые пишут на книги рецензии, оставляют отзывы, и в итоге вероятность найти то что нужно в сети часто опять же оказывается быстрее.
Файлы не должны именоваться, идеальная ФС эта та о которой пользователь не знает. Кстати хранить все в одном каталоге может вызвать некоторые проблемы с производительностью.
Именование по дате? Вот у вас есть файл, вы его сохранили неделю назад с соответствующей датой в имени, затем что то поправили в нем, должна ли дата быть свежей? или старой? А если вы забудете переименовать?
И так про многое можно сказать. Вопрос организации домашней базы знаний только кажется простым, чем дальше в лес тем больше косяков. Множество копий сломано, а никаких идеальных решений нет :( Все субъективно и криво. Вон KDE их Nepomuk лет семь назад запускали, а толку, всем плевать :( Хотя закваска была неплохая, но как раз невозможность обмениваться метаданными между системами и губит все.
Да, любые системы это очень индивидуально, кому то очень удобно работать с Evernote, кто то как не пытается не может с ним работать.
Списки ReadLater бессмысленны если их не чистить, а прочитанное не переносить в какую то систему знаний. Поиск по тексту файла к сожалению не сравнится с тем как ищут поисковики, постоянно совершенствуясь, а также пользователи которые пишут на книги рецензии, оставляют отзывы, и в итоге вероятность найти то что нужно в сети часто опять же оказывается быстрее.
Файлы не должны именоваться, идеальная ФС эта та о которой пользователь не знает. Кстати хранить все в одном каталоге может вызвать некоторые проблемы с производительностью.
Именование по дате? Вот у вас есть файл, вы его сохранили неделю назад с соответствующей датой в имени, затем что то поправили в нем, должна ли дата быть свежей? или старой? А если вы забудете переименовать?
И так про многое можно сказать. Вопрос организации домашней базы знаний только кажется простым, чем дальше в лес тем больше косяков. Множество копий сломано, а никаких идеальных решений нет :( Все субъективно и криво. Вон KDE их Nepomuk лет семь назад запускали, а толку, всем плевать :( Хотя закваска была неплохая, но как раз невозможность обмениваться метаданными между системами и губит все.
0
Спасибо за обстоятельный комментарий. Я сейчас понимаю, что многие важные вещи не сказал в статье.
1. Эту систему не нужно актуализировать в общем случае. Система на это не провоцирует, скрывая все файлы в общей куче. Изредка, нужно только править обнаруживаемую нецелостность (например, если обнаружили, что у Вас два значения параметра для одного и того же). Но это бывает действительно редко. По опыту двух лет такой работы могу это сказать.
2. Я совершенно согласен с тем, что если что-то можно эффективно найти в гугле, то незачем сохранять. Но это не про предложенный подход. Ибо если незачем сохранять, то никакой подход неактуален.
3. Список ReadLater обычно всегда безгранично разрастается. Это по сути очередной Inbox. Я просто предложил прием держать этот Inbox в состоянии Zero изначально.
4. Хорошо бы, если бы файлы не надо было именовать. Но это невозможно. Например, я хочу иметь возможность отобрать все свои идеи по проекту, которые меня посещали. Если я не маркирую их «o=thought», я их потеряю. А это реально сильно парит.
5. Дату, как и прочее, трогать никогда не приходится. Я ее использую как дату создания содержания впервые, таким образом она неизменной остается.
6. Главная фишка подхода — он предлагает что внести в имя, то есть предлагает ответить на три главных вопроса. Nepomuk, он не про это. Эту главную фишку подхода можно даже использовать с Nepomuk.
7. Проблемы с производительностью действительно могут быть. У меня пока нет. Но это не проблема: можно создать папку на год. Важно, что останется преимущество: вы не осуществляете навигацию по каталогам.
1. Эту систему не нужно актуализировать в общем случае. Система на это не провоцирует, скрывая все файлы в общей куче. Изредка, нужно только править обнаруживаемую нецелостность (например, если обнаружили, что у Вас два значения параметра для одного и того же). Но это бывает действительно редко. По опыту двух лет такой работы могу это сказать.
2. Я совершенно согласен с тем, что если что-то можно эффективно найти в гугле, то незачем сохранять. Но это не про предложенный подход. Ибо если незачем сохранять, то никакой подход неактуален.
3. Список ReadLater обычно всегда безгранично разрастается. Это по сути очередной Inbox. Я просто предложил прием держать этот Inbox в состоянии Zero изначально.
4. Хорошо бы, если бы файлы не надо было именовать. Но это невозможно. Например, я хочу иметь возможность отобрать все свои идеи по проекту, которые меня посещали. Если я не маркирую их «o=thought», я их потеряю. А это реально сильно парит.
5. Дату, как и прочее, трогать никогда не приходится. Я ее использую как дату создания содержания впервые, таким образом она неизменной остается.
6. Главная фишка подхода — он предлагает что внести в имя, то есть предлагает ответить на три главных вопроса. Nepomuk, он не про это. Эту главную фишку подхода можно даже использовать с Nepomuk.
7. Проблемы с производительностью действительно могут быть. У меня пока нет. Но это не проблема: можно создать папку на год. Важно, что останется преимущество: вы не осуществляете навигацию по каталогам.
0
БЭМ для файлов?
0
Примерно тоже самое, только применяю к каталогам — а файлы внутри уже по обстановке.
0
Sign up to leave a comment.
Эффективное управление личными файлами